Unexpected entry into event case

[Jordan Kuehn]

Hey guys

I could use some help. Basically I have a vi that entered into a case triggered on a front panel boolean value change. However, this boolean is continually enabled or disabled and grayed out during the timeout case based upon a different controlling boolean. (a quick and dirty admin mode if you will).

The operator claims that the button was grayed out the entire time and that the state was entered into without any action on his part after the subVI began to run.

Any thoughts? I'm having trouble explaining why it got there.

[Aristos Queue]

Sorry... no ideas come to mind.

[Jordan Kuehn]

After looking at it several times, we may just have to go with the obvious option. It behaved as expected and the operator didn't want to admit it.

[Yair]

Also, just to be on the safe side - a value change event is also triggered if you call the Value (signaling) property on the control, which is relatively easy to check by looking for all of the control's references or property nodes. This doesn't cover everything (e.g. someone using the pane's Controls[] property, but it covers most of it. Also, this can't be done for latched booleans, so if it's latched, you can also know it's not that.

[Black Pearl]

My guess is that another event case was executing (and showing it's SubVIs FP). During this, a click was performed on the suspected button (has to be enabled) on the Main VI. When the SubVI was closed and the event was finished, the queued up event was proceeded. Propably a more complex variation of this, which did also do the disabeling&greying out.

Felix

[Jordan Kuehn]

Also, just to be on the safe side - a value change event is also triggered if you call the Value (signaling) property on the control, which is relatively easy to check by looking for all of the control's references or property nodes. This doesn't cover everything (e.g. someone using the pane's Controls[] property, but it covers most of it. Also, this can't be done for latched booleans, so if it's latched, you can also know it's not that.

There is no use of the value (signaling) property in the VI, and no access to the Controls[] is being done. It's a fairly simple subVI.

My guess is that another event case was executing (and showing it's SubVIs FP). During this, a click was performed on the suspected button (has to be enabled) on the Main VI. When the SubVI was closed and the event was finished, the queued up event was proceeded. Propably a more complex variation of this, which did also do the disabeling&greying out.

Felix

Perhaps my description wasn't clear enough. The two buttons in question reside on the front panel of the subVI which behaves like a dialog prompt. There are two event structures, on in the main vi and one in the sub vi; however, the action in question was the action triggered by that button value change in the subvi.

[Yair]

Perhaps my description wasn't clear enough. The two buttons in question reside on the front panel of the subVI which behaves like a dialog prompt. There are two event structures, on in the main vi and one in the sub vi; however, the action in question was the action triggered by that button value change in the subvi.

There is one option I can think of here - that the user double clicked the button in the subVI and that the subVI closed after processing the first click. The event structure then remembers the second event and processes it the next time the subVI runs. I have seen this happen before, but this doesn't seem to match your description, though.

I've actually been thinking of posting an idea to the idea exchange for a feature which would prevent this from happening, but I couldn't come up with a good method of preventing this and it is a relatively rare occurrence, as it only happens with users who double-click buttons.

[Jordan Kuehn]

There is one option I can think of here - that the user double clicked the button in the subVI and that the subVI closed after processing the first click. The event structure then remembers the second event and processes it the next time the subVI runs. I have seen this happen before, but this doesn't seem to match your description, though.

I've actually been thinking of posting an idea to the idea exchange for a feature which would prevent this from happening, but I couldn't come up with a good method of preventing this and it is a relatively rare occurrence, as it only happens with users who double-click buttons.

Perhaps, but I think in this case it would be about as unlikely as the user having tabbed several times, hit enter, and did it again. That button hasn't been used for quite some time.

And perhaps the value change event structure could capture double click events in a similar fashion to how windows does it? Then it could be a boolean input into the case.