DblClick event on listbox crashes Excel when I move the listbox as a result of the event

Hi all, long-time lurker, first-time poster.

I'm currently struggling with a strange problem. Let me try to explain what I'm doing.

I have a userform with two listboxes side by side, one is wider than the other. On form initialization, the left side has a list of computers, the right side (initially the wider one) has a list of software installed on the computer selected on the left. This data is imported from a LANDesk query result.

I have two radio buttons to switch modes in how these listboxes are drawn, such that I can instead see all possible software titles on the left side, and selecting a piece of software on the left shows a list of all computers that have that software on the right. This all works perfectly.

When I switch view modes, the listbox widths change because I want the one that will show the software title to be much wider than the one that shows the computer names. This is working fine also.

I decided that I want to also be able to double-click an item on the right side, which will switch the views around and select what I just double-clicked on the newly-redrawn left side. This way when I am in the "By Computer" view, with the software list on the right side, the view switches when I double-click a specific piece of software, so that now I can see all the computers that have that software. And if I double-click one of those computers now, it switches again so that I am now seeing the contents of that computer. This is working great too.

But then I found a serious problem with this setup. I've managed to mostly trace the logic of what's going wrong but can't figure out how to get around it. When I double-click on the right, if the right-side listbox is currently the wider of the two, and my mouse cursor is far enough to the right when the double-click happens, Excel crashes. I've got it worked out that the safe zone (where it works great) in the wider listbox is from its left edge to exactly the width of the smaller of the two listboxes. This is because it shrinks to that size as part of the switch-around, and for a very brief moment, the mouse cursor is no longer over the listbox and the DblClick event is still executing. So I figure the event is becoming invalid because of this.

If I resize the listboxes inside the DblClick event AND DO NOT CALL ANY OTHER CODE, then I can double-click anywhere along the width and it doesn't crash. This is even if as an experiment I move the listbox way out of range, the event doesn't break. But as soon as I call more code from within the event, and have moved the listboxes, Excel crashes. I need that event to do both things, and it does only as long as I am careful where I click, which is not acceptable. If I call the other code (which is also where the listboxes normally get their sizes switched) but comment out the size-switching part, it doesn't crash. But I need both the sizes to change, and to be able to call the other code, without falling foul of the DblClick event getting trashed. If I put this functionality into a button instead, it works, but doing it with a double-click feels very intuitive and obvious, and I really want to be able to do it this way but safely.

So the question I'm trying to ask is: Is there some way that I can trigger the size change and the report-switching code from outside the DblClick event somehow? Like I mean have the event set a flag somewhere, then we leave the DblClick event, and THEN my code gets called by some other event? Like a timer? I have no idea where that would go, what would I trigger it with?

This is what I've got in the DblClick event currently:

Please Login or Register  to view this content.

ReportByNode and ReportBySoftware are the radio buttons. Setting one of them to true triggers their event:

Please Login or Register  to view this content.

BuildReportList called with True makes it build the list by computer name, and false makes it build by software title. So ReportByNode.Value can be used for both because if ReportBySoftware is true, then ReportByNode is automatically false.

So I thought, well I'm in an event from another event, so what if I Call BuildReportList(true/false) from inside the DblClick event in case the radio button event is messing it up? But that has the same problem. I can't change the listbox size and call outside the event when the mouse is far enough right, only one thing or the other thing, unless the mouse is in the safe zone. It's driving me crazy!

I wouldn't have this problem if both listboxes were the same width, but it is necessary to change them around because otherwise the computer list has a ton of unused space that makes it look bad.

I found out what to do. My question of how to defer execution until the DblClick event had completely passed was the correct line of thinking.

I replaced the code in the event with:

Please Login or Register  to view this content.

And made a sub called SwitchViewSelect in a module. I put my radio button change in there. It executes 1/10 of a second later, long after the DblClick has passed, and works fine regardless of the mouse position since that is no longer relevant by the time the code runs. Sleep had not worked by the way, in case you wonder since this maybe sounds like the same thing. This OnTime function does not wait or halt, it schedules execution for a later time while continuing current execution, that was the solution I needed, a scheduler.

Maybe someone will find this useful as this answer is too late for the OP.

Within the double-click event of the listbox we can set the 'Default' property of a button to 'True' and use

Please Login or Register  to view this content.

to make sure we trigger the click event of that button asynchronously.
After that we could set the 'Default' property to False if needed.
If we already have a button with a 'Default' property set to 'True' we should temporarily set it to False and restore to True before exiting the double-click event i.e. have the correct button with the 'Default' property set to 'True' when we use 'SendKeys' and then restore state as it was.