Unbound Field Behavior Problem

[nag9127]

I have this code attached to the BeforeUpdate property of an unbound field which is a fixed field set to zero decimals. I want the default for the field to show a zero (0) and have set that property accordingly. The code works properly when inputting anything into the field, but if the user simply tabs or enters thru the default 0, the code doesn't work. If I type 0 in the code works but if I enter thru the default 0 it does not. I take that to mean that the field does not execute the BeforeUpdate routine when the default is accepted without input. Is that what is going on and how can I modify this to work the way I want it to. Having the field default to nothing works, but I'd rather not do that. I want the zero to show.

If Me.QuantityProduced > 0 Then
    Exit Sub
    Else
    MsgBox "You Must Enter a Positive Number in Quantity Produced!", vbOKOnly + vbCritical, _
    "Positive Quantity Required!"
    Cancel = True
    Exit Sub
End If

On a side note, why isn't my code showing up properly in these posts. Am I not using the code brackets properly? Thanks!

 

[RuralGuy]

Your assumptions about the events are correct. Try putting code in the exit event which fires regardless of update when tabbing through the control.

RuralGuy (RG for short) aka Allan Bunch MS Access MVP acXP winXP Pro
Please respond to this forum so all may benefit

 

[nag9127]

I've tried Exit and LostFocus and the problem with those is that my forms always allow an "Exit Without Save" command button to take the user out of the menu at any time. If you use the Exit and LostFocus events, I can't exit the menu using the "ExitWithoutSave" command button because the Exit or LostFocus code intercepts that option and runs in a loop.

 

[PHV]

In the ExitWithoutSave_Click event procedure set a global variable you can test in the Exit/LostFocus code.

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[TheAceMan1]

How are ya nag9127 . . .

You have to take account of a users intent not to save (a user tabs over the unbound field of a new record, with no intent of entering any data in the record. Here your forcing an unintended record! . . . see my point!

In any case, the forms BeforeUpdate event should suite you better. Be aware of using focus events as you'll find you won't be able to leave the form . . .

See Ya! . . . . . .

Be sure to see thread181-473997
Also faq181-2886

 

[nag9127]

Your comments about unintended saving of records is what motivates all my form construction. I don't set up any forms which allow records to be accidentally saved. Otherwise, I would have a full fledged disaster on my hands. Everything on the form is controlled as the user progresses through the fields until the user executes a "Save Record" command button at which point criteria is evaluated to allow saving or produce error/information messages and throw the user back to the field requiring modified input. But I also like to have error handling occur at the field level while the user is progressing through the form and that's what this problem is all about. I try not to ever allow a user to routinely exit a form and in the process save a new record. The standard Access menu bars do not exist on these forms and the user cannot progress through the end of the form using the tab key and save a record in the process. Your point about Focus events is right on and I am going to use the Form BeforeUpdate event to ultimately control the record saving process. In this case I was just trying to achieve clean error handling control at the textbox level. I could make the default value blank which would solve my problem. I was just hoping for something I might have been missing as a solution. As always thanks to all of you for responding!

 

[TheAceMan1]

nag9127 . . .

A last comment . . .

A forms [blue]BeforeUpdate[/blue] event is the perfect place to perform validation before a record is saved. No matter how vital the controls data may be, validation in the forms [blue]BeforeUpdate[/blue] event [green]catches them all![/green]

Be aware: The forms [blue]BeforeUpdate[/blue] event only triggers if the record was edited in any way. Here edited means, [blue]any character(s) entered in any bound control in a record![/blue] . . . As long as the user doesn't edit they can navigate to their hearts content.

No matter how critical data entry of a control may be, I give users full fair on data entry. Its always validation in the forms [blue]BeforeUpdate[/blue] event that nails them!

A logical run of what I typical have, looks like:

[blue]   Dim flg As Boolean
   
   If Me!TextboxName1 <> Your Condition Then
      MsgBox "Your Message!"
      Me!TextboxName1.SetFocus
      flg = True
   ElseIf Me!TextboxName2 <> Your Condition Then
      MsgBox "Your Message!"
      Me!TextboxName2.SetFocus
      flg = True
   [green]'
   '  Other Textboxes
   '[/green]
   ElseIf Me!TextboxNameN <> Your Condition Then
      MsgBox "Your Message!"
      Me!TextboxNameN.SetFocus
      flg = True
   End If
   
   If flg Then Cancel = flg[/blue]

Also be aware: The forms [blue]On Dirty[/blue] event triggers on the the first character you enter in any record, new or previously saved! You may also be able to make use of this.

You'll always know if the current record is being edited by the pencil icon

that appears on the record selector! . . .

[blue]Hope this helps! . . .[/blue]

See Ya! . . . . . .

Be sure to see thread181-473997
Also faq181-2886

 

[PHV]

nag, did you make sense with my suggestion (28 Feb 08 12:33) ?