Bug? Control updates itself after VI stops running.

[SteveChandler]

I just put together an example of using a notifier and a user event to communicate between two loops to help someone here. Pressing a button causes a notification to be sent to a loop which sends a user event back and then waits for 10 seconds. It then sends another event to signal it is complete. Simple. To stop the VI I use the Panel Close? event. That event sends a notification to the bottom loop to stop and stops the event loop.

Ok here is where it gets weird. If the 10 second task is running and you click the red X to stop the VI it imediately stops the event loop. Obviously the second loop is blocked until the 10 second wait is done. If during this wait time you click the red X then change the value of a numeric control, once the VI stops the control will keep incrementing.

Here is a screencast and a snippet.

[SteveChandler]

Oh, it stops incrementing when you either click on the front panel or move the VI window.

[Darin.K]

I do not have LV11 to even begin testing, but let me take a guess that there is a value change event case inside your Event Structure which is set to Lock the Front Panel.  It smells like the common situation where an Event Structure catches the event but will not wake up to handle it.  Try unchecking that option (assuming I am on the right track).

[RavensFan]

Very odd.  It took me a few tries to figure out exactly what you were doing before I could replicate it.  Basically, the increment or decrement arrow on the numeric control gets stuck.  But if I disable lock front panel until the event completes for the numeric control value change, then the behavior doesn't happen and the up or down action on the control value happens immediately.

It is like a weird race condition interaction between the handling of the UI event and the UI screen update that causes the increment/decrement arrow to get stuck on.  Like it is initially handled, but the UI lock then freezes it, and it never completes handling it when the UI is freed up although you have since moved the mouse off the control.

[SteveChandler]

Here it is in 8.2. I tested this with LabVIEW 2010 with the same results. It does not happen if I disable lock front panel in the event case for the numeric control.

[SteveChandler]

Yep, you are both right - the increment/decrement button is getting stuck. That is much less weird than I thought. I have a timeout event that executes at about the same rate as the increment/decrement when clicked and held. It seems like a pretty low priority bug but maybe a CAR?

[Chris-G]

Very interesting...

Yep. It seems like this may be a development bug. If this causes anyone serious problems please be sure to post here. Otherwise, it appears to not cause any major functionality problems and the workaround above seems straight forward and effective. I'll continue to look into it and post a CAR # if applicable.

[Chris-G]

This was reported to R&D (322699 CAR ID) for further investigation. Thanks for the feedback!

Chris G

[Chris-G]

The CAR ID has been changed. New CAR ID: 322844. Thanks!

Chris G