REQUIRE AN ENTRY BEFORE PROCEEDING IN A FORM 4

[JerSand]

A novice's question: A form's (and the associated table's) first field is "ID." I know that by making it the key, I can require that it contain a value. But that way, the user proceeds entirely through a record's entries before he/she is informed that the record can't yet be saved. How would one cause ACCESS to stop the user from entering any information for a record before entering an "ID" value?

Thanks.

Jerry

 

[tlbroadbent]

One possibility is to disable all other fields on the form until the ID filed contains a valid entry. Then in the "After Update" event, enable the other fields. Terry

http://members.home.net/tlbroadbent/index.htm

 

[dneufarth]

Somewhat easier may be to set the focus on the ID control/field and not allow movement to another control/field on the form until something is entered.

ID.SetFocus
Put code in the control's After_Update event to test for data.


Dave

 

[gusbrunston]

It's a good habit to define the field properties when you design your table.

Open your table in design view. Select your first field, "ID". In the field properties box below, select General tab; select "Yes" on the "Required" line. Then your form won't let you out until you have made an entry in that field (and that entry must conform to the Data Type, the Input Mask and the Validation Rule you may have in the other boxes in the field properties box.
Gus Brunston
An old PICKer
padregus@home.com

 

[PaulMilnes]

Dear JerSand

All the answers you have received will work fine, but I think there's a better way, avoiding some of the drawbacks. These are:

Disabling all the other controls and then enabling them once the user has entered an ID is fine, but will invoive a lot of enabling statements - if you have dozens of fields this would be a pain.

I like the idea of checking for a value before losing the focus (presumably this would go in the 'OnLost Focus' property but you have to be sure exactly which property is best, because the order of events (OnExit, etc.) may mean a bit of experimentation.

Making the field required is definitely a good idea, but your user will only be told when they try to move on - ie when they have already filled everything else in.

My preferred solution would be a dialogue box asking specifically for the ID only. You create it just like any other form, but set it to PopUp and Modal in the properties. You can also size it to come up in a little box of its own, just like an ordinary dialogue box. Give it an OK button and put code (or a macro) on this button's OnClick property so that it can check and give a message if the user has left the field blank.

Setting a from to PopUp means it can come up any size you like even if everything else is maximized, and Modal means the user can't click anywhere else outside it. (So give it a Cancel or Close (X) button as well, otherwise they could be stuck!)

The advantage of this method is that it's absolutely clear to the user that they have to provide and ID.

One other thought - are these IDs going in new records? If they are, and there's nothing special about them except that they provide a unique reference, then why not set the field to AutoNumber and let Access supply it? That way the user can never mistakenly enter a duplicate.

All the best

Paul

 

[tlbroadbent]

All of the suggestions have merit. Use the method that best fits your needs and experience.

One thought about disabling and enabling the controls on a form. This can be done quickly with little code using the Controls Collection. This assumes the ID is the first control on the form. Adjust as needed for you situation.

For i = m to n ' m= # of second control on form, n =# of last control
me.Controls(i).enabled=true
Next i

Place this code in the After Update event of the ID control. Terry

http://members.home.net/tlbroadbent/index.htm

 

[JerSand]

Thank you, Terry, Dave, Gus, and Paul. I'll try all the methods you suggest. I'm sure they'll all work, but trying each of them will be a good learning device.

I'm truly grateful for the fast and expert responses.

Jerry

 

[gusbrunston]

All good ideas.

I'm using Access2000. I wonder why when I enter "Required" for the 'ID' field, then build a form, make no entry in the 'ID' field, try to tab to enter something in the next field, I get an error message that the field cannot hold a null value? That means I don't fill in any other field before I'm told to finish the first (required) field. The following is from 'help':

&quot;The field <name> cannot contain a Null value because the Required property for this field is set to True. Enter a value in this field. (Error 3314)
The Required property for this field is set to True, prohibiting the entry of a Null in the field. Enter a value in the field.&quot;

But none of this makes any difference if the Avalanche lose game 7 on Wednesday night.

Gus Brunston
An old PICKer
padregus@home.com

 

[gusbrunston]

Please forget my last submission. Now MY forms aren't working the way I thought they were!
:-I Gus Brunston
An old PICKer
padregus@home.com

 

[JerSand]

Thanks for the follow-up, Gus. I thought perhaps the difference was that you're using ACCESS2000, whereas I'm using ACCESS97. Your kind message will save me from that exploration.

Go Aves.

Jerry

 

[gusbrunston]

Now I need to know:
Paul, (or anyone) how do you integrate the pop-up diaglogue box with a &quot;main&quot; entry form? Do you put it in as a subform?
Thanks, Gus
Gus Brunston
An old PICKer
padregus@home.com

 

[Francescina]

My contribution might look simplistic after all these valuable tips, but I always use the BEFOREUpdate event to check the values in this certain field.
If the criteria are not met a simple
&quot;CANCEL = true&quot; will force the focus to stay on this field.

With this very basic system you can create your own rules for indexed fields such as &quot;No duplicates&quot; but the value &quot;NONE&quot; or &quot;N/A&quot; or &quot;MISSING&quot; or anything else can appear an unlimited number of times.
You just define the table field as indexed with duplicates allowed and your BeforeUpdate code checks whether the value already exists. If yes-> CANCEL=true if no->proceed if the value is part of your exception group (&quot;NONE&quot;, &quot;N/A&quot;, &quot;MISSING&quot; or anything else) you continue to proceed.
Checking if the field is NULL or empty (Len(field & &quot;&quot = 0) is also very easy.