Avoiding a race condition in this scenario

[GregFreeman]

I have a listbox that is populated with all the different devices connected to a server. If a device is disconnected, the server will send a message to the client that the item was disconnected, and the listbox should have that item removed. Well, if a user double clicks an item in the listbox, I want to launch a window dynamically. What I'm worried about is the user will double click an item in the listbox and I will queue the row up that was clicked to the consumer loop, so the consumer loop can index the listbox item and launch the window. But, if before the message is put in the queue, the server sends a message saying to remove an item in the listbox then that message will be handled first.  If the item removed is listed before the item I clicked, the item will be removed and now my index that the user double clicked is associated with the wrong item and a VIT for the wrong item will be launched.

I am using OOP so if there is some blocking with in place element structures that I can use to my advantage to avoid this that is an option. 

Another option is I can index a property node within the event case and get the item name rather than handling it in the consuemr loop. But, I could run into the same problem where the click happens, the row clicked is returned in the event structure, then an item is removed in the consumer loop before the property node to return the listbox items executes within my evenet structure. The index gets off in this scenario too. Unless, when a property node is executing in an event structure, it is blocked in parallel loops. If this is the case, then this method would be safe becuase the consumer loop couldn't update the property node while the event structure was executing. But, I'm not sure whether or not this is what happens.

[tst]

That seems like a fairly unlikely race condition (at least with the second method) and seems like it would be within the normal tolerances (i.e. the user clicked just as the list was changing).

Some other options:

1. If you refresh the list, discard any further double click events which happened before you refreshed the list (you would probably need to check the time).
2. Just show the wrong panel.

[GregFreeman]

---

@tst wrote:

That seems like a fairly unlikely race condition (at least with the second method) and seems like it would be within the normal tolerances (i.e. the user clicked just as the list was changing).

Some other options:

1. If you refresh the list, discard any further double click events which happened before you refreshed the list (you would probably need to check the time).
2. Just show the wrong panel.

---

I figured I might be overthinking it. As I was posting I was thinking "what are the odds of this actually happening". I'll just go with method 2.

[johnsold]

Then add a message saying, "The device you selected was disconnected just as you clicked! If you get any luckier, buy a lottery ticket!"

Lynn

[Yamaeda]

If you send the name instead of the index you can verify that it exists before showing/removing it.

/Y