Jump to content

Event Firing Order - Need help


lavezza

Recommended Posts

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.

Link to comment

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.

Link to comment

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

Link to comment

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

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.

Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.