Jump to content

Unexpected entry into event case


Recommended Posts

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.