[AccessD] Filtered combos - Events don't fire

John W Colby jwcolby at gmail.com
Wed Mar 11 09:47:46 CDT 2009


A.D.

I got it all working finally.  The situation is as you describe, however 
it is also worse than you describe because of the issue of no combo 
events firing if the user clicks out of the subform entirely.  In that 
case the subform control has to reach back down into it's .Form.fclsFrm 
(my clsFrm instance for the subform) and call a .mUnfilterCbos() method 
which forces the combos to unfilter.  It then has to refresh the subform 
or the resulting unfiltered combos still don't display as unfiltered.

As you said, I do in fact have to use the OnEnter/OnExit but I also use 
the GotFocus/LostFocus.  I found a handful of cases where the gotfocus 
fired when the OnEnter didn't, specifically (I think) when the combo in 
the form "had the focus" i.e. the cursor was in it, but the user had 
clicked out of the subform.

In any event I decided that just hooking all four events - focus and 
enter, did no harm and covered all bases.

What a PITA this was!  I am sure there was some logic in the Microsoft 
Programmer's brain when they set this stuff up, but they failed to share 
the logic with the world.

In any event, it finally works.  In the end, the most complex part was 
the subform control' OnExit having to reach down into it's form and call 
my clsFrm instance to call mUnfilterCbos(). 

For whoever asked, this is why I expose the fclsFrm as a public variable.

A.D.Tejpal wrote:
> John,
>
>     There is an interesting reason for the problem faced by you. It has to do with the weird behavior of a control's GotFocus and LostFocus events, making such events unsuitable for the objective sought by you.
>
>     With focus on combo box, if you progress through the records by pressing PgDn / PgUp keys, GotFocus and LostFocus events of this control keep firing alternately, in step with record change and nothing appears amiss.
>
>     However, if an attempt is made to step through records by clicking navigation buttons on the subform, Lost focus event fires and you are stuck with it (visually, the combo appears to have focus, but it is in LostFocus state). There is no further firing of GotFocus or LostFocus events. Drop down list of combo box shows the unfiltered state. Again, if PgUp / PgDn is done, normal firing of these events resumes and things are back to normal.
>
>     If you move out of the subform (say by clicking a control on parent form), while the focus was on its combo, exit event of subform control fires. LostFocus event of combo does not yet fire at this stage. Now, if you click a navigation button on the subform, combo's LostFocus event will fire (preceded by subform control's enter event) and you are stuck with combo in LostFocus state, even though it looks like having focus. 
>
>     Similar phenomenon takes place, if after moving out of the subform, you try to step through its records via some control on the parent form (In such a case, subform control's enter event won't fire).
>
>     In short, use of GotFocus / LostFocus events can not ensure consistent results as their firing can be sporadic, with the potential to get stuck in LostFocus state (in this state, even direct clicking on combo box does not cause firing of GotFocus event and full unfiltered drop down list gets displayed).
>
>     Solution:
>     ---------
>     The solution is drastically simple. Use enter and exit events of combo box. Alternate firing of these events is consistent under all circumstances and remains in synch with record navigation.
>
> Best wishes,
> A.D. Tejpal
> ------------
>
>   ----- Original Message ----- 
>   From: jwcolby 
>   To: Access Developers discussion and problem solving 
>   Sent: Friday, March 06, 2009 18:43
>   Subject: Re: [AccessD] Filtered combos - Events don't fire
>
>
>   Yep, this is where I am headed.
>
>   This is the reason that I keep the clsFrm public in a form header, it allows other objects to reach into the form, grab a pointer to the clsFrm and tell it to do things (like reset the combo queries).
>
>   Unfortunately this is a little over the head of my target audience in the Classes and Events lecture series.
>
>   John W. Colby
>   www.ColbyConsulting.com
>   
-- 
John W. Colby
www.ColbyConsulting.com




More information about the AccessD mailing list