Button _Click event does not execute immediately

[L Mehl]

Hello --

My multi-field form has (for purposes of this question)
txtField1
and
cmdSave.

Code modCalcs on txtField1_Exit has logic depending on whether or not the
user is saving the record. I use a boolean blnIsSaving to know which part
of the logic to run. Clicking cmdSave should set blnIsSaving to True;
otherwise blnIsSaving is False.

My problem:
With txtField1 having focus, clicking cmdSave runs the code on
txtField1_Exit immediately instead of acknowledging the Click.
modCalcs sees blnIsSaving = False, instead of True, as should have been
caused by clicking cmdSave.

Can anyone tell me how to immediately trap the click of cmdSave so I can set
blnIsSaving to True?

Thanks for any help.

Larry Mehl

 

[Allen Browne]

Before Access can move the focus to the command button, it has to move it
out of the text box. It follows that the Exit event of the text box will
*always* execute before the button's Click event can.

You could solve that issue by using a toolbar button instead of a command
button.

But the best solution will probably be to learn how to work *with* the
events Access fires for you instead of against them. Assuming this is a
bound form, Access will fire the BeforeUpdate event of the form when the
record is about to be saved. You can therefore use Form_BeforeUpdate to run
any validation, checks, assignments, etc that need to be run before the
record is saved. And you can be sure that this will always work regardless
of how the save happens--even if that occurs by moving record, applying a
filter, changing the sort order, pressing Shift+Enter, saving through the
menu, closing the form, closing Access, and so on. The only exception is a
serious glaring bug with Access that is documented (with workaround) here:
http://allenbrowne.com/bug-01.html

You probably won't need to use the Exit event of txtField1 then. In general,
you will use the control's BeforeUpdate event if you want to check the entry
is valid and keep the user there if it is not, or the AfterUpdate event of
the control if you want to change something else that depends on this entry.
The Exit event fires regardless of whether anything changed or not, and so
is generally inefficient.

 

[L Mehl]

Hi Allen --

Thank you very much for explaining the relevant form and control events.

I agree about working *with* the events. Your descriptions will help me do
that. I had things really screwed up.

Larry