Event Firing Order - Need help

[lavezza]

We have discovered a problem and I would like some help from the community to see if this is widespread.

I've attached a VI that I'd like everyone to run.

The user changes a numeric control and then immediately clicks in a listbox. The Value Change event for the Numeric gets the value of the listbox and displays it in a dialog.

On most of our machines, the listbox value changes after the Numeric Value Change event. On some it changes before.

On the machines with the odd behavior, it shows up in 7.1.1 and 8.2.1.

If you follow the instructions on the front panel, I think you should get zero. Some users get two. I'd be interested in seeing what other people get.

VI saved in 7.1.1

Thanks,

Pat

P.S. I did do a search on LAVA, NI Forums and NI KnowledgeBase. I didn't find an answer.

[PJM_labview]

Win XP, LV 8.21

Getting 0 here.

PJM

[Justin Goeres]

QUOTE(lavezza @ Aug 27 2007, 09:20 AM)

I've attached a VI that I'd like everyone to run.

Test machine is a Dell Inspiron 9300 laptop under WindowsXP (Dog only knows which updates).

LabVIEW 8.5: "Listbox value: 2"

LabVIEW 8.2.1: "Listbox value: 2"

LabVIEW 7.1.1: "Listbox value: 2"

My recollection is that there were some issues in the past with the timing of front panel terminal values in relation to Value Change events, but I don't remember what version(s) they existed in. That's the reason why I always use the NewVal terminal in a Value Change. That doesn't exactly apply to your situation, but it's similar.

[lavezza]

OK, we just did some more testing. On my machine, it seems to always work as expected all the time. On my co-workers machine (where we first saw this problem) we are seeing that it sometimes works, sometimes not. Damn.

[bmoyer]

WinXP

8.2.1=0

8.0.1=0

7.1.1=0

Seems to be working fine here as well although I have seen some weird event handling with 8.0.1 on occasion (can't remember the exact situations, just remember that event handling and screen updates are faster and more reliable when using an exe than when using the source code).

Bruce

[Justin Goeres]

QUOTE(lavezza @ Aug 27 2007, 10:38 AM)

OK, we just did some more testing. On my machine, it seems to always work as expected all the time. On my co-workers machine (where we first saw this problem) we are seeing that it sometimes works, sometimes not. Damn.

I added a sequence structure around the listbox terminal and forced the dataflow, and that seems to have forced the Listbox terminal to read late enough that I get the "after" value every time. I tested it maybe 10 times.

http://forums.lavag.org/index.php?act=attach&type=post&id=6774''>http://forums.lavag.org/index.php?act=attach&type=post&id=6774'>http://forums.lavag.org/index.php?act=attach&type=post&id=6774

[lavezza]

QUOTE(Justin Goeres @ Aug 27 2007, 12:51 PM)

I added a sequence structure around the listbox terminal and forced the dataflow, and that seems to have forced the Listbox terminal to read late enough that I get the "after" value every time. I tested it maybe 10 times.

http://forums.lavag.org/index.php?act=attach&type=post&id=6774''>http://forums.lavag.org/index.php?act=attach&type=post&id=6774'>http://forums.lavag.org/index.php?act=attach&type=post&id=6774

Well, it's nice to get it to work consistently. Unfortunately, it would be consistently wrong (at least based on the way we think it should work). We've already written a work around for this particular VI, but it would be nice if it worked the way we all think it should.

[Justin Goeres]

QUOTE(lavezza @ Aug 27 2007, 11:12 AM)

Well, it's nice to get it to work consistently. Unfortunately, it would be consistently wrong (at least based on the way we think it should work). We've already written a work around for this particular VI, but it would be nice if it worked the way we all think it should.

Fair enough, but I'll take consistent, with a workaround over random chance any day, even if it's not what I think is "correct" .

I would also be interested to hear if the behavior is different on platforms other than Windows.

[MikaelH]

But if you place the List Box Value event after the Numeric Value event it should probably work?!?!

I guess it's depending on the speed of your computer if it has time to do the event numeric change before the list box value change.

I put a small timeout in the example and got the "wrong" behaviour, and then I just rearranged the events and it worked again.

Cheers,

Mikael

[hfettig]

I am running a P4 with WinXP and LV 8.5

I constantly get a 2 in the message box.

I also determined that the events are fired in the correct order.

First the 'value changed' event for the numeric is fired, then the 'value changed' event for the listbox is fired.

I think what you are really seeing here is a classic case of race conditions.

Remember that the 'value changed' event is a notification event, not a filter event, meaning it is fired after the value has changed.

Since you are actually reading the listbox control (which is a completely separate event, from the value changed event) inside the numeric event handler, it depends on machine speed whether LabView has already processed the value change event of the listbox by the time the numeric event handler reads the listbox control.

The main problem seems to be that both value changed events are the result of a single front panel action, meaning that clicking on the list box triggers both events. This make the 'Lock front panel until the event case for this event has completed' effectively useless since the second event has already been fired.

Unfortunately LabView does not supply the 'Validating' notifier event that windows fires when the focus is about to leave the numeric control. This way you could make sure to handle the numeric value change before the listbox change occurs.

I guess as a work-around you could store the list box value in a shift register every time the 'value changed' event of the listbox is handled and then use the content of the shift register to display the message in the numeric event handler.

Alternatively you could check the 'Key Up' events of the numeric. However, that event would not fire if you paste in a value using the menu, and it would fire 5 times for a five digit number.

As far as this being a problem, I don't think that this is a LabView bug since events are fired in the correct order.

However, I can see this causing problems if you need to validate a changed value (in a control that accepts typed text) before any other values are allowed to be changed.