Solved Listbox AfterUpdate and click when there is no selection

[Pat Hartman]

I'm running O365 with a fairly recent update.

What is June7 running?

 

[Luis Fernandez]

No Access 2016 32 bits spanish version

That could be the difference

June7 what is your access version?​

 

[Pat Hartman]

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?????

 

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

 

[Pat Hartman]

Messing around with when events run can break applications. MS shouldn't be doing that without a really good reason.

 

[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?

 

[Pat Hartman]

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

Those are the only two arrows I see.

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

But then logically the Got Focus should occur before the Enter (which I thought was how it worked before I built this database). They should bracket the other events.

([ )] Instead of ([ ])

Either Enter/Exit is within the two focus events or the two focus events are within the Enter/Exit It is jaring. Some events should be paired.

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?

 

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

 

[Pat Hartman]

They differ in terms of when they occur. Exit occurs before LostFocus.

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

 

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