Re: Control Exit event kills Button Click Event in Access2002 Form

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Mike Elliott (Elliott_at_discussions.microsoft.com)
Date: 10/20/04 

Date: Wed, 20 Oct 2004 08:51:02 -0700

I left out an important detail. The Exit procedure determines which field to
move to next. The DoCmd.GotoControl statement in the Exit procedure moves
the focus to a third control.

This causes a problem because users have to Click the button multiple times.
 Each click fires the "Exit" Event for whichever control has the focus. When
they get to a control with no Exit event, then the Click event for the button
will fire.

I created a new form to test this with. I dropped 3 fields onto it as well
as a command button. The Exit event for the first field moves to the third
field. The Button just displays a message.

When I click the button, the focus moves to field 3. When I click it again,
my message is displayed. If I select the second field (with no exit event)
and click the button, my message displays immediately.

However, I then went back and tested this simple form in Access97 and it
behaves exactly the same way. I had never noticed this behavior before. I
was wrong earlier when I said that they behaved differently. I should have
done the simple test in both versions before posting the question.

I appreciate the quick responses and hope I have not wasted your time.
Mike

"Dirk Goldgar" wrote:

> "Mike Elliott" <Mike Elliott@discussions.microsoft.com> wrote in
> message news:5F325D6E-F4E4-40B6-A21D-43F1DD879B6A@microsoft.com
> > Access 2002 Forms behave differently than Access 97 Forms.
> >
> > ControlA has the Focus and I click ButtonB. If there is an Exit
> > event for ControlA, it will Fire, but the Click Event procedure for
> > Button B never fires.
> >
> > In Access 97, The Exit Event would have fired and then the Click
> > event for the button would fire.
> >
> > My workaround was to use the Change event where possible and not the
> > Exit or LostFocus events.
>
> I'm using Access 2002, and I don't see the misbehavior you describe.
> Are you sure you aren't doing something in the Exit event for ControlA
> that would prevent ButtonB from receiving the click? Canceling the
> event, perhaps?
>
> --
> Dirk Goldgar, MS Access MVP
> www.datagnostics.com
>
> (please reply to the newsgroup)
>
>
>

Relevant Pages

  • Re: R> DROP in GForth
    ... It provides powerful flow control for slightly less overhead ... So maybe you could reverse the flow of arguments and first tell us ... flows remaining until you reach a structured exit. ... and wherever it starts getting snarled you can do a LOB like ...
    (comp.lang.forth)
  • Re: Username & ComputerName With Access2003
    ... > The before insert only exists for the whole form, not a particular control. ... then again you should be able to "exit" without a record being ... Remember, when you exit a form, no prompts occur, ... and then on the properties sheet for that control, ...
    (microsoft.public.access.formscoding)
  • Re: Event order when clicking away from a field
    ... I have found a rather neat way of making the control ... being held until the exit event is completed, ... Optimistic locking would be great if everybody had a good server, ... the active control in the subform in order to make another control ...
    (microsoft.public.access.forms)
  • Re: Username & ComputerName With Access2003
    ... > programmer, and I have no idea what you are saying. ... The before insert only exists for the whole form, not a particular control. ... if the user decides to exit out of the form without saving ... and then on the properties sheet for that control, ...
    (microsoft.public.access.formscoding)
  • Re: R> DROP in GForth
    ... It provides powerful flow control for slightly less overhead ... So maybe you could reverse the flow of arguments and first tell us ... flows remaining until you reach a structured exit. ... and wherever it starts getting snarled you can do a LOB like ...
    (comp.lang.forth)