The complexity of Controls' Events

[Sun_Force]

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.

 

[CJ_London]

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

KeyPress Event - Post.Byes

I'm trying to capture when a user presses a particular key (escape), so I'm coding in the KeyPress event. Yet the code seems be bypassed (breakpoint is never encountered). Should I be coding in a different event? Is this a known issue? FYI, this is happening in both Access 97 and 2000.

bytes.com

you might want to bookmark this link for order of events

Order of events for database objects - Microsoft Support

support.microsoft.com

 

[Sun_Force]

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

KeyPress Event - Post.Byes

I'm trying to capture when a user presses a particular key (escape), so I'm coding in the KeyPress event. Yet the code seems be bypassed (breakpoint is never encountered). Should I be coding in a different event? Is this a known issue? FYI, this is happening in both Access 97 and 2000.

bytes.com

you might want to bookmark this link for order of events

Order of events for database objects - Microsoft Support

support.microsoft.com

@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]

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]

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.

Solved - OnExit or Lost Focus for TextBox in Subform

Hello Dears, I have a subform and a column "Discount" and i have some code on OnExit event for Column "Discount" and it works fine, but when i click out of subform then the event OnExit does not triggered?? can u explain what is the reason and how to solve the issue..... regards,

www.access-programmers.co.uk

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.

 

[The_Doc_Man]

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:

Order of events for database objects - Microsoft Support

support.microsoft.com

 

[MajP]

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]

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.

 

[MajP]

One final thing. If you are not familiar, at times this is the answer.

DoEvents function (Visual Basic for Applications)

VBA language reference

docs.microsoft.com

 

[The_Doc_Man]

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]

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).

 

[gemma-the-husky]

@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

 

[Sun_Force]

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)

 

[Isaac]

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]

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]

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]

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]

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.

 

[Sun_Force]

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.

I like the idea. I may use it for the next assignment. If it's OK....
(though we've been strictly asked to use our own ideas....Receiving hints and help to achieve our goals is OK, but copying the whole work is not allowed)

 

[MajP]

I do the same in most of my DBs. I use a textbox and set the value to =SomeCaption. This way it can be active control and you can use a single function instead of writing lots of event procedures.. Then I set the tag property to the sort string. Usually this is more than just the primary field because most times it may not make much sense not to have additional fields sorted if you sort by the clicked field.. Something like "OrderNo, DrawingNo,...". Whe they click check if DESC follows OrderNo if not add DESC else use the tag by itself.
As pointed out no control I know of can do both the single and double click. But you can use a mouse down instead of the click event. Then you can capture something like a shift or a right mouse (have to disable the menu though). In a recent thread I suggested t that so they had a normal mouse down and a shift mouse down do different things. It worked well.

You could also make this a 3 way click. Asc, Desc, back to default. Not sure if that is any simpler.