Explain this MS help on Lost focus?

[twgonder]

This is the kind of gibberish in the online helps that drives me nuts. I've read it 10 times and I can't figure out what they are trying to say.



Is the control on the subform different that the subform control???



Does the enter event run or not? If it's a form "control", and not a control on the form, where the heck is the Form's On Enter in the properties?

Form.LostFocus event (Access) | Microsoft Learn

[isladogs]

Is the control on the subform different that the subform control???

Yes.
The subform control is part of the main form. It is the container holding the subform
The control on the subform is ... precisely that.

Access has to enter the subform container (control) in order to set focus on a control within the subform iself

Personally I thought the part of the article you quoted was well written - certainly not gibberish

[twgonder]

@isladogs post #2. Okay, thanks, that got me going in the correct direction. I created the main form some months ago, and for the past two days have been working only in the design of the subform (with lots of hiccups there), which made me a bit myopic I suppose. Still getting the swing of all the vocabulary.

[Edgar]

The subform control is a... "control", of course, that holds one form/report inside. Therefore, if it's holding a form, then the subform control will inherit a Form class from which you can access the Form it's holding, but if it's a report, it will inherit a Report class. That's very important to remember.

So, to answer your question, Does the enter event run or not?
If the control with focus is in the main form and you click in a control in the subform's form, the following happens:
ControlInMain_Exit
ControlInMain_LostFocus
SubFormControl_Enter
ControlInSubFormsForm_GotFocus
ControlInSubFormsForm_Click

If the control with focus is in the main form and you click in a control that is different from the one that used to have focus in the subform's form, the following happens:
ControlInMain_Exit
ControlInMain_LostFocus
SubFormControl_Enter
PrevControlInSubFormsForm_GotFocus
PrevControlInSubFormsForm_Exit
PrevControlInSubFormsForm_LostFocus
CurrentControlInSubFormsForm_Enter
CurrentControlInSubFormsForm_GotFocus
CurrentControlInSubFormsForm_Click

If the control with focus is in the subform's form and you click in a control in the main form, the following happens:
SubFormControl_Exit
ControlInMain_Enter
ControlInMain_GotFocus
ControlInMain_Click

If the control with focus in in the subform's form and you click in a control in the main form different from the one that had focus, the following happens (the same):
SubFormControl_Exit
ControlInMain_Enter
ControlInMain_GotFocus
ControlInMain_Click

So, as you can see, the author of what you read didn't talk about the click event or the mouse movements (mouse movements happen a lot), instead, the author went with a practical, although incomplete, explanation. I tell you that not from a book but from my digging. By reverse engineering Access and adding Debug.Print "EventName" to all events in the form, you can gain valuable insights on the events that occur with each thing you want to test, as well as the order of execution. Adding Stop routines to inspect your variables in the locals window can also provide you with a wealth of undocumented information, particularly in the case of Form variables. By doing that, I ensure that I am well-informed and avoid confusing and misleading information presented by individuals who claim expertise online. They don't like me though

[twgonder]

@Edgar post #4, Thanks for the complete description of your finds. I've been adding the equivalent to the "debug.print "EventName"" suggestion for some time now. I see all kinds of creepy things happening when done with all the monkey business of starting a form. I get what you mean by questioning the "experts" here (some get quite abusive).

Here is what happens on just starting the subform with two records (see the number of times Form_Current ran--this really slows down startup of the form, and messes with variables. I can't figure a logical reason for five runs with just two records):

[twgonder]

A follow-up on my post #5
I thought that maybe three times for running Form_Current might make some weird sense, in that some calculated data may need to be done for each record (which I do). Watching things in the immediate window, I see that Access bounces back and forth between the main and subform, each time running Form_Current. But then I checked to see which record the Form_Current was running for, and each time it was for just ONE record (the first one)! So, not only do we not get to run the calculated values for each record that might need something to display in the form, Access is repeating the Form_Current event seven times for two records, one for the main and one for the sub! Good grief MS!