Problem with Control ENTER & EXIT Event Firing with Frames Active

[SeaLyon]

I'm having some trouble getting control ENTER & EXIT events to fire properly when having controls embedded on frames within a userform. I'm using Excel 2003, 2007, & 2010. Here's the userforms I'm working with:

With FRAME:

Without FRAME:

In both cases, the DESCRIPTION field is disabled. The selectable controls on both are a combo-box, textbox, listbox, & 2 buttons. On the FRAMED version, the combo-box & textbox are contained on a FRAME.

Here's the code, same on both userforms:

Option Explicit

Private Sub cmbRecipes_Enter()
  ListBox1.AddItem "ENTER - " & cmbRecipes.Value
End Sub

Private Sub cmbRecipes_Exit(ByVal Cancel As MSForms.ReturnBoolean)
  ListBox1.AddItem "EXIT - " & cmbRecipes.Value
End Sub

All this is doing is posting a message to the listbox when the combo-box ENTER & EXIT events fire. This works as expected without the FRAME, ENTER is shown when the combo-box is entered and EXIT is shown as focus is moved to another control. But when running it on the FRAMED version all I get is a single ENTER event recorded regardless of how I move the focus through the control set.

Another oddity is that if I have more than 1 control that can receive focus on the FRAMED version, it appears to work correctly. Any ideas on what is causing this problem?

Thanks,
Chris

 

[mikerickson]

Enter and Exit events can be quirky. I use BeforeUpdate and AfterUpdate more than Exit.

About your Enter problem, have you tried a Frame1_Enter event that looks at the ActiveControl. (Note that Frame1.ActiveControl may not be the same as Userform1.ActiveControl)

You might also want to play with the Frame1.Cycle property.

 

[SeaLyon]

Thanks for the info. Another little wrinkle is that my application needs to run on all Excel versions from 2000 thru 2010. The really simple fix here is to just get rid of the frames since I'm really only using them for aesthetics. But I'd like to understand this problem a bit more before I take the simple path.

The weird thing is that this problem appears only if I have ONE selectable control in the frame. If there are more controls, than the events seem to fire correctly. I have played a bit with the CYCLE options, but that doesn't seem to affect the results. I'm also not sure which version CYCLE was added, so I'd need to be careful about that.

Do you know what version the BeforeUpdate & AfterUpdate events were added? I haven't tested them yet, but I will give that a try.

I also haven't attempted to trap the frame's event to see if I can get the info I need from there, but I'll play with that to. Do you know if any changes have occurred with the ActiveControl property thru the versions?

Appreciate the help.

 

[mikerickson]

AFAIK, all those properties and events are in all those versions.
Removing the Frames seems the most robust solution.
By "apperance" do you mean the Frame will be visible to the user or is it an (invisible to the user) aid to moving blocks of controls about.

If nessesary, i.e. if the controls move at run-time, you could write a custom class that keeps the controls in the same relationship to each other.

A transparent Label behind the controls could mimic the appearance of a frame.

 

[shg]

Removing the Frames seems the most robust solution.

I second Mike's suggestion.

 

[SeaLyon]

I totally agree, removing the FRAMES makes the most sense (& probably what I'll do). I'm not doing anything fancy with the FRAMES, they are just used for visual grouping for the user. I can find other graphic methods to address this without issue.

But, I am interested in gaining a better understanding of this problem. This seems to be linked to the number of selectable controls in the frame. With 1 or more selectable controls it appears the EXIT event for the last selectable control in the frame DOES NOT FIRE. However, the FRAME_EXIT event does fire with the ACTIVECONTROL set to the last control in the frame. So, I guess that could be coded for. However, if the frame only has 1 selectable control, it DOES NOT FIRE the ENTER event for that control. If it has more than 1, it DOES.

I don't agree with this functionality and can't see a reason why it should work this way, but at least I think I understand what it's doing. Does anyone have an idea why the event firing should be working like this? Is this a bug or a feature?

 

[shg]

To my knowledge, it's a bug. Or at least I've never heard it well rationalized as coherent and consistent behavior.

 

[tfurnivall]

Yes - I think it's a bug. However, it's been around so long (and always bites me in the rear-end) that it's now a Feature, so it won't be changed

 

[maxpit]

Hi SeaLyon,

I think that by reading this you might find some interesting ideas ... Breakthrough in the Pseudo-Control-Array ( clsBpca Ver 4.0 )

See you soon.