Solved Listbox AfterUpdate and click when there is no selection

[June7]

I am doing what I described above. Click on listbox scrollbar to make it active control then press up/down cursor keys to move through list.

If by "down arrow", you mean listbox scrollbar, then that is what I click on.

I have now viewed Pat's db. As I cursor through listbox (did not click into, just on scrollbar), I see the other form has new records whereas in my db, code to filter does not happen. I set breakpoint in listbox AfterUpdate event and it is triggered with each cursor movement.

So now the mystery for me is why my code does not affect form recordset and Pat's does with cursor movement.

 

[June7]

I did not say clicking on scrollbar fires events, cursor key movement does.

 

[Luis Fernandez]

Interesting.
The elevator or lateral control bar only scrolls and does not execute any events.
The down arrow always does the 3 events (Before/after/click) in this order
The click always makes the 3 events (Before/after/click) in this order
Try it yourself, when you finish your bridge game, lol, no rush and thank you very much, really

 

[Luis Fernandez]

Ok I think I remember that this is an access setting that we are fighting over, or a different version, this using 2016 32 bits for now

 

[Luis Fernandez]

No Access 2016 32 bits spanish version

That could be the difference

June7 what is your access version?​

 

[Luis Fernandez]

Another possible problem, although you are already on your way out, lol
Thank goodness I've already solved it anyway here
Muchas gracias a todos, creo que lo mejor es dejarlo así. error de versión antigua
And thank you very much for your version of the event system, it helps a lot.

 

[Mike Krailo]

WOW!!! I just noticed that Exit runs before LostFocus. That is bizarre. I thought the "exit" side events run opposite the "enter" side events. so 8. should be LostFocus and 9. should be Exit?????

But if you don't ever Exit first, how can you possibly lose focus? That would mean you never exited in my mind.

Right off Microsoft website:

 

[June7]

Please clarify what is meant by "down arrow" in relation to listbox. Is this the arrow on scrollbar?

 

[Mike Krailo]

I'm not even sure why we have both Enter/Exit and Got/Lost Focus. Is there some different purpose they are supposed to serve?

They differ in terms of when they occur. Exit occurs before LostFocus. They differ in the respect that the Exit event can be canceled, LostFocus cannot. So, which one you use depends somewhat on what you want to do in that event.

 

[Edgar_]

Based on my development experience during the creation of my sample, I'd say MS didn't think this one through or they left it unfinished. Evidence:
1. If you do this with listbox.ItemsSelected( you get a tooltip that says Item(Index) As Long. If you then remove the initial parentheses like listbox.ItemsSelected you get a tooltip that says ItemsSelected As _ItemsSelected, Giving you access to the internal name of the class, which should be private, hence the underscore. If it behaved like other well coded classes, the tooltip would say Local ItemsSelected As ItemsSelected, or just ItemsSelected As ItemsSelected.

2. ItemsSelected has an item property, but I couldn't get it or set it. Either I didn't test it well, or they just added a property that returns nothing. I guess it's inheriting an array interface? but only the count seems to work.

3. There is no distinction in the items selected for the before and after update of the listbox.

4. The value of the multiselect listbox is null regardless of being bound or unbound, value only works when the listbox is it's not a multiselect

5. In .NET, there are .SelectedIndices and you can also cast the selection to a string using .ToString(), in MS Access VBA, that is simply not possible.

Thanks, I understand, but the user sees the order in a live form/report

The sample would give you that ability. The last snippet returns a msgbox with the constructed string. You can then split it and loop through it to populate the live form/report.

@Pat Hartman I think OP refers to a down arrow as the keyboard's down arrow, not the scrollbar.

 

[Mike Krailo]

That doesn't mean anything Mike. It's like saying the Open occurs before Load.

Every event is a "hook". There is a huge amount of code that runs behind the scenes of a form that makes it work. We can't see it and we can't change it. The original MS developers added "hooks" in their mainline code where they could let us hang our custom code to do certain things. Every hook has a specific purpose and is intended for certain types of "user" (that's us) code. For example, it makes no sense to put validation logic in the Current event of a record because that event runs before any data ever gets typed into a form.

The most useful documentation that MS could provide for events is what types of logic THEY intended the "hook" to handle. The events are not random. They each have a specific purpose but some are muddy.

So the following is the "bracketing". It is not clear to me why two sets of brackets are provided. I can sort of understand why the LostFocus doesn't have a cancel event. That would essentially leave you in never, never land between two events. But, OK, then why would you not put the hook for the GotFocus first and the Enter second? IF MS would give us actual, logical samples for what type of logic they envision for each of these events, developers would find that very useful.

Private Sub lstStates_Enter()
    Call LogEvent(Me, "lstStates_Enter")
End Sub
Private Sub lstStates_GotFocus()
    Call LogEvent(Me, "lstStates_GotFocus")
End Sub

'''.....other events are between these

Private Sub lstStates_Exit(Cancel As Integer)
    Call LogEvent(Me, "lstStates_Exit")
End Sub
Private Sub lstStates_LostFocus()
    Call LogEvent(Me, "lstStates_LostFocus")
End Sub

The key part that you left out of my quote is that the exit event is cancelable. Makes sense to me. Taken out of context, yes I agree with you.

 

[Mike Krailo]

Every event is a "hook". There is a huge amount of code that runs behind the scenes of a form that makes it work. We can't see it and we can't change it.

This statement is really puzzling to me. If you can't see it, then how do you know there is a ton of code behind it? Maybe you worked for Microsoft, I don't know. Without seeing it though, I would reason that it is merely a hook as you say and there is not much code behind it at all. It's doesn't seem like there is much to it as all it has to do is consider which controls could get the focus in the case of On Lost Focus, or which controls can be exited from. We're talking about a couple of event hooks for a single listbox control. But if you look at all the controls that have an exit and a lost focus, they sure appear to do the exact same thing me. That's what classes do, right? Why would any programmer make a special Exit event for for every control, when you could just make one single exit hook for all controls that it applies to. Isn't that the whole idea of a class? Sure wish we had a Microsoft insider that could verify all of this sort of stuff.

BTW, I'm asking because I'm not the expert here, I'm trying to learn about this too so please don't take this the wrong way.

 

[Edgar_]

Why would any programmer make a special Exit event for for every control, when you could just make one single exit hook for all controls that it applies to

Access source code is not public, so nobody here can possibly know that without having worked directly with it. And if someone did I have a bunch of questions that need answers.

I can only guess that the controls use a system that watches what's happening with other parts of the program, like classes and interfaces, by employing a listener or observer design pattern. The reason they all seem to have similar events might be because it makes it easier for us the developers to create the programs, not because they're events inherited from something else. Another possibility is that there's a "container" object that emits these events, and when you put your control inside it, it automatically gets those events. Eh, it's just a guess.

 

[Josef P.]

[OT]

Why would any programmer make a special Exit event for for every control, when you could just make one single exit hook for all controls that it applies to. Isn't that the whole idea of a class?

Let's assume that the Exit event would be included in the Control interface and that all other controls would inherit from the ControlClass.
Then a Label or Line control would also have to have an Exit event. That doesn't fit, does it?
You could use another class "FocusableControl" in the background, which encapsulates the exit function and inherit from it. However, this might create too much dependency. (Inheritance also has its downsides).