Full Version: Loading a form and having empty fields on your screen
UtterAccess Forums > Microsoft® Access > Access Forms
The problem.
ser loads up a form and the form shows a number of boxes that are text and combo boxes showing the contents of a record from a table. However I want the the user to be met with blank fields when first loading.
The problem is that certain users start typing away before pressing the "create new" button. As such data is overwritten and lost. Despite training and grief at said users. frown.gif
I have tried a procedure on the "Form Load" where I used the txtEmployeeID = "" etc. But it doesn't allow for easy alteration or expansion. Having the need to go in and add or delete the boxes that need to be filled in. Also didn't work on some of them. (I think to do with record type.)
Is there a quick "With everything make blank" kind of Vb call or some way of tricking Access into going to the end of my records instead of the beginning?
The create new method I used threw up a blank record at the beginning of my table each time and so it quickly became flawed with gaps everywhere.
HAs always any help much appreciated.
Place this on open event module ...
oCmd.GoToRecord , , acLast '**** to goto the last record
DoCmd.GoToRecord , , acNewRec '**** to goto the new record
GOOD LUCK !!cool.gif
Do you mean place it on the open_event for the form.
FOr create a module and link to it with an open event?
Look at the form's Allow Edits, AllowDeletions, Allow Additions, and Data Entry properties.
Is this form being used only for adding new records?
If so then set the Data Entry property of the form to Yes.
If it is to be used for editing/viewing etc.
How is the form opened?
Do you have a main menu with buttons to open the form?
I would create buttons for each way you need to open the form.
Use the Open form method of the DoCmd object
DoCmd.OpenForm "FormNameHere", , , , acFormAdd
DoCmd.OpenForm "FormNameHere", , , , acFormEdit
DoCmd.OpenForm "FormNameHere", , , , acFormReadOnly
Sorry okay a little background.
The database is split using the wizard of access and works in that regards fine.
Their is a main screen acting like a switrchboard though I did it, not the 'switchboard' access does. clicking between screens using buttons and VB code to open and close as needed. The VB code I used to move between forms was 'openform' and then a 'closeform' closes the open one. (That make sense)
The form in question has data entry boxes, text, tick boxes and combo boxes with linked lists. all these boxes link to the data table that holds the records of the clients. formats include date, long integer and text, usual affair in that regards.
The form property is set to add & edit as the user can and should be able to.
"Delete" is a msgbox confirmation before you can delete. This is linked to a button elsewhere on the screen as they need to want to do it and not be able to accidentally.
I have actually used the acFormReadonly on a checking screen elsewhere for a quick check that general users can use to see a small section of information. (Name and address)
When opening the screen it sets a few boxes invisible as they need to have a tick box set to yes first, and does a few other things like brings up the days date etc.
What I need was the boxes to all be blank. Something in the form load, open or activate events.
It seems to me that you got several ways to do what you want. I think however, there is an issue here with what you deem as "blank". When you open a form in Edit mode, it will open with a record displayed. The only way (on a bound form) to have all the controls blanked is to open the form to a new record. You can accomplish this, either by opening the form in Add Mode or by going to a new record (I didn't include using Data Entry mode since you said they can use the form for editing as well). I think the going to a new record will probably fit your needs best.
If you want open the form ALWAYS to a new record, then put the second line Jay gave you in the On Open event of the form. If you want to go to a new record only sometimes, then I would use the Open Args parameter to pass a value to the form, then use something like this:
If Me.OpenArgs = "blank" then
New Record
End if
"Blank" I mean an empty field value. No data. Not to be saved just to be blank / empty etc little squares of background colour. frown.gif
tried automatically going to a "new recrod" but it does create a new record at the beginning of my data set. So my unique field (Primary key, and must not be blank) that is the EmployeeID is now blank - that throws errors for being blank in a "must be" filled field.
Not making it required means that I get a blank record in the table. I have tried the suggested route by Jay and even my own function "newrecord" shamelessly nicked from the 2003 developers VBA handbook. (Very good book indeed)
Just looking for an alternative to a new record if there is one.
Ohaven't tried it yet as the program is in development. But would two users on the FE opening the form together create two new records... what would happen in my table. That is a worry at the back of my mind.
The software will be used by a dozen users when up and running. Just to make your lives interesting.
Cheers again thanks.gif
Sounds to me like you may not want to use bound forms. Like I said, the ONLY way to get blank controls on a bound form is in Add record mode. If that doesn't work for you, then you may want to unbind the form and provide your own method for appending records. You may want to have two forms, one for adding and another for editing (the latter can be bound).
This is the first generation so to speak. For a pilot at my work.
But once up and running I am probably going to have to update the whole shebang. So multiple input screens will have to be the answer if that is the only real way.
Unbound forms though. Hmmm not tried them before - any idea or warning of pitfalls?
Cheers again.
There isn't a problem with multiple forms, you Can clone a form and adjust as necessary. Unbound forms become more complex since you have to code the interaction with the tables manually.
ts not as difficult to add records from an unbound form, but retrieving and edit records is.
I often (not always) use unbound forms to create a new record in my bound form. I use it like a template with a "Save" button. If the user likes what they entered on the unbound form and want to 'save' their work, they click the Save button and a SQL statment will append the data from the unbound form to a table. I then have an almost indentical form that's bound to this table. If you want to see ALL records, then you open the form that's bound to the table.
I don't us multiple forms. To much confusion when i have to fix or change something. I use the same form and just bind and unbind the controls as need be.
nbind the control
Forms!MyControl.ControlSource = ""
bind the control
Forms!MyControl.ControlSource = "MyField"
this way only one form. Takes a little more coding but saves on maintence.
good luck
DFish - Do you mean "on load" unbind as above so the user sees a blank form
When when they do something "on update" for example, do the "bind" code?
When would you use the code to bind and unbind to get a blank field?
fiftyfour- in theory sounds good, but that adds one level of complexity that I think would confuse users. Having to save their work through pressing a button. I can see the appeal, but my users might not. I can see them complaining at the extra effort involved (they want words on buttons not pictures as they might misunderstand a pair of binoculars for a FIND button.)
There are two basic ways I handle this.
) open the form in dataentry mode.
DoCmd.OpenForm "FormNameHere", , , , acFormAdd
The sets the data entry mode to yes and the uses does not see any old records. Only the records they add.
In the on current evet ten all the allows (add, edit delete) to no.
Then have a ciommand button the turn then allows on.
Boyd, same thing I was going to suggest...I would set the forms allow edits to No on open, then if you try to type something it won't allow it. Once you click a button or check a box then it sets the forms allow edits to true and you can edit. This way you don't have to mess with Adds or deletes. I think the users deletes are already handled with a confirmation.
I will look into that. I have used data entry by mistake and got used to the effect it causes.
eletions are a not an issue as they (the users) can't. But I will take a look at using that method.
Here is a problem linked to this.
When doing the New rec' method. User goes in and it generates a new record for them. If they don't do anything and go a for a dinrk or answer the phone or somthing. Basically take them time away from filling it in the following error message appears. The time preiod is a matter of ten minutes and upwards.
"You cannot go to the specified record
When clicking Debug it takes you to the line calling the new rec function.
It is as if the system times out.
Anyone any thoughts?
Is this a multi-user database?
Yeah.... same database as the rest of this thread. Same problem on the whole. :(
It the moment it is in development and so only one user is using it to input a test data set for me to then build some reports and queries, and it has yet to be split.
hope that helps.
Are the users typing in part of the record at all or not typing anything? If they aren't typing anything in yet and it is doing it, you could just add the code to requery the form every 5 minutes or so. That might do the trick. Not for certain, but worth a try.
Not at all at the moment, just the team leader.
That would the code be to kick off every five minutes
Oknow the requery code, but not the time delay to start it.
I assume it would be best to do it as a function.
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.