[2005] syncing up listboxes without the delay

[Desolator144]

I want to make my program extra fancy and sync up two listboxes with this code:

Private Sub lstQNum_SelectedIndexChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles lst1.SelectedIndexChanged
        lst2.SelectedIndex = lst1.SelectedIndex
    End Sub

and the opposite for the other one. But of course there's about a half second delay before the correct item gets highlighted in the opposite listbox and it's VERY noticeable. I tried using suspendlayout and resumelayout which did nothing i tried manual refreshes in various places and they didn't help I tried it with threading and you can't access a control from a thread it wasn't created in or you have a Microsoft moment (even if it's declared as public!) I tried doing the suspend and resume layout technique using selectedvaluechanged and selectedindexchanged since value fires first and that didn't help. I can't think of anything else to try so is there another way that you guys have gotten it to work in the past?

[jmcilhinney]

To say that there's half a second delay is an exaggeration unless you're very slow on the mouse. The delay you see is cause by the fact that the item is highlighted on the mouse down but the SelectedIndexChanged event isn't raised until the mouse up. This is because you can mouse down and then move the mouse and the highlighted item will change as you drag. It's not appropriate that the SelectedIndex change as you're dragging because the selection hasn't been made until the mouse button is released.

Maybe you'd care to stop adding a dig at Microsoft to all your posts. This happens for a reason, you can't access controls across threads for a reason and their implementation of SQL is as standard as anyone else's. If you don't understand how something works it's not the creator's fault. If you were to stop assuming that things should work a certain way and take offence when they don't and rather look at things with an open mind and try to understand the reasons things work as they do then you'd find solutions more easily. A relatively simple mechanism is provided to access controls from worker threads. Not that one is needed here. If you want instant gratification from the second ListBox then you can get it but you're not going to be able to use the SelectedIndex to sync the two. There's no reason for the user to expect it though.

[Desolator144]

If you don't understand how something works it's not the creator's fault.

if you walk into a store and can't find an item you're looking for for 15 minutes and when you ask an employee they say "well we laid the items out in ascending order by serial number," who's the blame for the item not being found? I'll give you a hint, the employee's not going to last very long if he tells the customer he was stupid for not seeing their logic in how they laid it out even if it makes sense to them. People that make products need to design it for their customers and since Microsoft invented the language and there's no class called "all of the visual basic language" then I suggest they set it up in a way that the majority of people find logical who don't know much about it. Or at least put some how to style articles instead of technical documentation articles in the MSDN library, which there are pretty much none of.
As for the listboxes, I'm faster with the mouse than most people and the delay is that bad regardless of how fast I click, as you can see in this demo:

and before you even say it, I've got a 4400+ X2 and BFG6600GT and a GB of ram.
What event actually does trigger to change the highlighting during a mouse holding slide so I can sync up with that instead? It seems like it would be fast enough (btw don't bother suggesting multicolumned listboxes cuz anything that MSDN gives an example of that looks that complicated isn't worth doing when you're on a limited timeframe)
Btw this code:
lstCorrect.SuspendLayout()
lstQNum.SuspendLayout()
lstCorrect.SelectedIndex = lstQNum.SelectedIndex
lstQNum.Refresh()
lstCorrect.ResumeLayout(True)
lstQNum.ResumeLayout(True)
doesn't work. How is telling them both not to draw anything anymore, making them have equal values, refreshing the second one just in case even though it won't show, then telling them both to redraw and having it not fix the problem anything but stupid on Microsoft's part? It's literally not doing what the methods say they do. Also I walked through it and VS crashed, as well as on the college computers too.

[jmcilhinney]

SuspendLayout on the ListBox, which you intend to prevent it redrawing, then you call Refresh, which specifically redraws the control, then you call ResumeLayout so the control will redraw. Sounds a little... odd to me.

Try adding two ListBoxes to a form. Now add the same number of items to each. Now add the following code:

Private Sub ListBox1_SelectedIndexChanged(ByVal sender As System.Object, _
                                          ByVal e As System.EventArgs) Handles ListBox1.SelectedIndexChanged
    Me.ListBox2.SelectedIndex = Me.ListBox1.SelectedIndex
End Sub
 
Private Sub ListBox2_SelectedIndexChanged(ByVal sender As System.Object, _
                                          ByVal e As System.EventArgs) Handles ListBox2.SelectedIndexChanged
    Me.ListBox1.SelectedIndex = Me.ListBox2.SelectedIndex
End Sub

Now run the project and click some items in each control. You'll see that there is a delay before the two lists sync. Now try using the arrow keys to move up and down one of the lists. You'll see that the two stay perfectly in sync. The delay you saw initially was the delay between the mouse button being depressed and the mouse button being released. It's possible to work things out with some investigation. I've also explained why this is the case and not stupid at all.

If you want to follow the highlighted item in the ListBox then you'd have to use the DrawItem event and check whether the State of the item being drawn is Selected. If it is then you would set the SelectedIndex of the other ListBox. This will take some thought so as not to get in an endless loop of the two controls provoking each others events. I've never used the DrawItem event in my life. I just looked down the MSDN member event listing for the ListBox and eliminated those that couldn't be useful and investigated those that could. When an item is highlighted or not it must be redrawn

I don't love Microsoft or think they're perfect, but people bagging them because everything isn't exactly as it should be annoys me. You can obviously post whatever you want but if people annoy me then I'm less likely to help them. If you're fine with that then go on bagging them as you have been. Otherwise open your mind and accept that things will not always be exactly as you want or expect but that doesn't make them bad or stupid or wrong. I have been using MSDN as my primary resource for .NET development from the beginning, since I had less experience than you do now. It hasn't always come first go or without effort but I've almost always been able to find most or all of what I want there. If I can do it then anybody can and I believe that anyone who can't just isn't trying hard enough.