The complexity of Controls' Events (1 Viewer)

Sun_Force

Member
Local time
Today, 16:59
Joined
Aug 29, 2020
Messages
186
Maybe I should rephrase the title.
The complexity of controls' Events For Newbies.

I see a bunch of similar events for controls and I can not understand how they differ from each other.
I know (read somewhere) there's a certain order for these events to happen, but how the effect of these events on the result is different remains a mystery.

Some of them are reasonable. I can understand how Before_Update differs from After_Update and how they can be used in different situation, but isn't Enter the same as GotFocus? I can't imagine a scenario when the code should go to Enter but not to GotFocus and visa verse.

Exit and LostFocus are two more.
Is there any specific situation a code should be written for Exit that can not be used in LostFocus?

Is there a situation when you needed to run a code after a user press a key and before the textbox changes? (On_KeyDown event vs On_Change)?

KeyDown and KeyPress are two more confusing events?

Let's take a checkbox as an example with its 4 events : Click/GotFocus/Enter/beforeupdate.
If you click a checkbox, the focus moves to the checkbox, mouse enters the control and it changes.
How many times you needed to put a code in on_Click of a checkbox and using the other GotFocus or BeforeUpdate couldn't satisfy your purpose?

Note: I know someone can use the tab key to move between controls. In this case only GotFocus event is fired. But do you really need to run a code even when the focus is moved to a control with tab key?

Any insight is much appreciated.
 
Last edited:

CJ_London

Super Moderator
Staff member
Local time
Today, 08:59
Joined
Feb 19, 2013
Messages
12,947
the difference is subtle but essentially you can enter a control once but set the focus many times. In most cases it won't really matter. See this link (useful for you to browse for all your questions) https://docs.microsoft.com/en-us/pr...e/developer/office-2003/aa211385(v=office.11)


use a search term like 'access vba keypress v keydown' and you will find your answers - this for example

you might want to bookmark this link for order of events
 

Sun_Force

Member
Local time
Today, 16:59
Joined
Aug 29, 2020
Messages
186
the difference is subtle but essentially you can enter a control once but set the focus many times. In most cases it won't really matter. See this link (useful for you to browse for all your questions) https://docs.microsoft.com/en-us/pr...e/developer/office-2003/aa211385(v=office.11)


use a search term like 'access vba keypress v keydown' and you will find your answers - this for example

you might want to bookmark this link for order of events
@CJ_London
I've already read many articles about the importance of each event, their order and how they are triggered.
I really hoped someone could suggest a situation where it makes a difference if I use On_Exit instead of On_LostFocus.

For now, I'm off to read your links and see what new information they have for me.

Thanks again for your input.
 

Isaac

Lifelong Learner
Local time
Today, 00:59
Joined
Mar 14, 2017
Messages
4,734
The LostFocus event differs from the Exit event in that the LostFocus event occurs every time a control loses the focus. The Exit event occurs only before a control loses the focus to another control on the same form. The LostFocus event occurs after the Exit event.
TextBox.LostFocus event (Access) | Microsoft Docs

Always look to the documentation - straight from the horse's mouth so to speak

I'm actually glad you brought this up. Up to now, if I had to pick what I thought was a catch-all, I'd probably have picked Exit. Reading this makes me realize that if I am going to be lazy and consider either one a catch-all, I'd better choose Lost Focus.

Every post on AWF has value in some way or another - I learned something new, thanks @Sun_Force
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 03:59
Joined
May 21, 2018
Messages
4,879
I am pretty knowledgeable on Access events. but this one got me recently where neither the lostfocus or on exit worked. Fortunately Pat pointed out the simple solution.
The issue was the OP wanted code to run when leaving a control on one of the two subforms. This control was the last control on the first subform. The code never seemed to run when they went to the second subform.

The reason is partially explained by @Isaac. The OP never went to another control on the SAME form they went directly to another form, and the OP never even exits the control for that subform. When you click on another subform it does not exit the first. This required the form's Before update which will occur when leaving the form for another subform as well as leaving a control.
 
Last edited:

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 02:59
Joined
Feb 28, 2001
Messages
19,633
And to add to the fracas: When you have events that are triggered by your actions in another event, remember that Access is single-threaded. One event cannot interrupt another, although the newly triggered events can SOMETIMES slide their way into the event processing queue. Because what is really going on is there is a execution-of-events queue that gets populated when Access first declares an event (say, for example, while loading a form). SO... you get Form_Open then Form_Load. A form could have been resized by a Form_Load action, so the Form_Resize will then occur. The form will be activated at that point, so Activate kicks in. Then, if the form is bound, you get Form_Current.

For controls, it of course depends on the control. Continuing from the above discussion, if at least one control is bound and is enabled as a tab stop, tab-stop ordering will cause that control to gain focus. This is a case where the control_Enter and control_GotFocus event fire, in that order.

The best page for this that I have found as a tech reference is:

 

MajP

You've got your good things, and you've got mine.
Local time
Today, 03:59
Joined
May 21, 2018
Messages
4,879
Also remember many control events only happen when you physically do something and are not caused by modifying the control in code. Changing the value of a control in code does not cause the chain of events.
Things like changing the focus and changing the current record of a recordset will trigger events.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 02:59
Joined
Feb 28, 2001
Messages
19,633
AND remember that it matters whether the control (or the form, for that matter) is bound or unbound. ANY event that requires underlying data just does not happen on an unbound object. Case in point: A totally unbound form has no _Current event, _BeforeUpdate event, or _AfterUpdate event.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 02:59
Joined
Feb 28, 2001
Messages
19,633
:giggle: But of course, my dear wife points out that if the answer was "chocolate" then the actual question doesn't matter.

(Sorry, struck a whimsical chord...)
 

Isaac

Lifelong Learner
Local time
Today, 00:59
Joined
Mar 14, 2017
Messages
4,734
Seeing all these replies I can't resist. And to add one MORE thought! If you find yourself doing Call Event, you may have started down a dark road and need to re-group. (May).
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 03:59
Joined
Feb 19, 2002
Messages
31,689
As a newbe, concentrate on understanding ONE event. The form's BeforeUpdate event. This is the most important event of all the form and control events. It is the last event to run before a record is saved and it cannot be bypassed so it always runs no matter what precipitated the save. This event is where the bulk of your validation code needs to go and if a validation rule is violated, you simply set the Cancel property to true and that prevents Access from saving the record. Control is returned to the user and he can fix the problem or use the esc key to back out his changes so he can exit without saving.

I occasionally use control level events but very rarely. People use them when they want absolute control over data entry. So they try to prevent a bad entry rather than catching the error and preventing the save. It's a point of view. My point of view is, I am never going to be able to figure out all the potentially wrong things a user might try to do so I'm not going to even bother. I'll just examine the values before the record is saved and ensure they conform to the rules. My way is of course not the only way. It is probably the lazy person's way (I've been writing code since 1968. I've written my million lines of code and I don't need the practice) but is ultimately the safest way since I act as the goalie and put my foot on the door and close it rather than trying to stop be puck mid field. (I'm sure that's a mixed metaphor, but you get the picture)

When I do use the control events is when I want to stop the user early. For example, I don't want him to create the entire employee record if he doesn't have a unique Social Security Number. So, in the BeforeUpdate event of SSN, I use dLookup() to see if the SSN already exists and if it does, I won't let the user enter it. If he doesn't have a valid SSN, he just has to go and get one first. This is more user friendly than allowing him to fill out the whole form and then preventing him from saving. So, I always put fields like this as early as possible in the tab order. But of course, I am not inclined to force a user to go field to field in the order I specify so I also have to revalidate in the form's BeforeUpdate event just in case the user bypassed the SSN.When I do use the control events is when I want to stop the user early. For example, I don't want him to create the entire employee record if he doesn't have a unique Social Security Number. So, in the BeforeUpdate event of SSN, I use dLookup() to see if the SSN already exists and if it does, I won't let the user enter it. If he doesn't have a valid SSN, he just has to go and get one first. This is more user friendly than allowing him to fill out the whole form and then preventing him from saving. So, I always put fields like this as early as possible in the tab order. But of course, I am not inclined to force a user to go field to field in the order I specify so I also have to revalidate in the form's BeforeUpdate event just in case the user bypassed the SSN.

A typical validation event might be:

Code:
If Me.DOB & "" <> "" Then
    if Me.DOB > Date() then
        MsgBox "Date of Birth must be < today.", vbOKOnly
        Me.DOB.SetFocus
        Cancel = True
        Exit Sub
    Else
        If DateDiff("y", Me.DOB, Date()) > 75 then
            IF MsgBox("Employee is > 75 years old.  Is that correct?"), vbYesNoCancel = vbYes  Then
            Else
                Me.DOB.SetFocus
                Cancel = True
                Exit Sub
            End If
        End If
    End If
End If
 
Last edited:

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 08:59
Joined
Sep 12, 2006
Messages
14,465
@Sun_Force

Assuming it doesn't matter which you use, exit, or lost_focus. Here's an example of a use for that event.

Some apps highlight the active control by changing the appearance - eg to a coloured border, and back to a normal border.
In which case, they may well do that with the on enter and on exit event, or maybe the ongotfocus and onlostfocus. Now if you do that, and then want the same event to do something else, you can either double up on the usage, or maybe you can use the other event.

Note. I actually have a note in my code that onenter and onexit seem to be more reliable that ongotfocus and onlostfocus, but I am not sure why. It's a long while since I added the code! I also have a note in there recording the use of some ideas from BobLarsen and ChrisO, of this forum.

You ask
Is there a situation when you needed to run a code after a user press a key and before the textbox changes? (On_KeyDown event vs On_Change)?
I don't think it's so much... is there a situation? It's just that all the events occur in a particular order, and the developer can use any event to achieve the precise control he needs. So it's more that the events occur at a very precise atomic level. It's better to have that level of granularity if you need it. We don't very often, as @Pat Hartman just said, but we might need it one day.

eg MS has this to say on the order of the exit and lostfocus events, and presumably why one may be more appropriate than the other. Exit occurs first, anyway. Exit only occurs if you move controls on the same form. Lost focus occurs if you change the focus to another form.

TextBox.LostFocus event (Access) | Microsoft Docs
 
Last edited:

Sun_Force

Member
Local time
Today, 16:59
Joined
Aug 29, 2020
Messages
186
One last question if you don't mind.

Have you ever been able to fire a function on double click of a command button?
No matter how fast I double click a button, On_Click event is triggered and not On_DblClick. (I'm just testing different events not that I really need a command's on double click)
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 03:59
Joined
Feb 19, 2002
Messages
31,689
and the developer can use any event to achieve the precise control he needs.
Events are not interchangeable. One will always be more "correct" than another since they wee all designed with specific purposes in mind. The documentation on events and why each should be used is weak.
No matter how fast I double click a button, On_Click event is triggered and not On_DblClick.
That's what I mean. In this case, I think both should run. First the click event and then the dbl-click but MS disagrees.
 
Last edited:

Isaac

Lifelong Learner
Local time
Today, 00:59
Joined
Mar 14, 2017
Messages
4,734
Have you ever been able to fire a function on double click of a command button?
No matter how fast I double click a button, On_Click event is triggered and not On_DblClick
I had no problem creating a message box that fired in the double click event of a button just now.

Of course, it would make no sense to have both a click and a double click event ...
 

isladogs

CID VIP
Local time
Today, 08:59
Joined
Jan 14, 2017
Messages
14,739
You can certainly run code on a double click event.
What you can't do is have separate code on a click event and ever get the double click code to work
 

Isaac

Lifelong Learner
Local time
Today, 00:59
Joined
Mar 14, 2017
Messages
4,734
One thing I do a lot is change a button immediately after its click event.
1) enabled=false
2) italic=true
3) caption="Please wait, processing..."
(change it back at the end).

Nice visual cue to the user, especially users who are power clickers.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 08:59
Joined
Sep 12, 2006
Messages
14,465
Events are not interchangeable. One will always be more "correct" than another since they wee all designed with specific purposes in mind. The documentation on events and why each should be used is weak.

Yes. What I meant was because there so many events available, the developer should be able to find a way of achieving what he wants to .
 

Sun_Force

Member
Local time
Today, 16:59
Joined
Aug 29, 2020
Messages
186
Of course, it would make no sense to have both a click and a double click event ...
Different cases requires different senses.
As I said it was just a test. In a continuous form, I changed all the lables into transparent buttons, the click of each button, calls a sort function to sort the form ASC or DESC according to that field, and adds a small triangle to the caption to show the sort. A double click calls the same function to clear the sort and set it to form's default order. Just like windows explorer when you click titles.
With a small difference. I change the font color to red. So I can easily understand which field is sorted.

Now that as @isladogs says using both on_Click and On_DblClick is not possible, I changed the buttons back to labels and did the same routine. The problem is labels don't get the focus, so I had to use a work around to pass the field name to the function.
This is the result. The following image shows that OrderNo is sorted DESC. Again, it's not a real life situation. Just an assignment for my class.

2021-02-22_7-51-23.jpg
 
Last edited:

Users who are viewing this thread

Top Bottom