Mouse Down? prompt

[miguelc]

I'm having a problem with the Mouse Down? filter event on a certain button (lets call it the OK button). I am using it to prompt a user with a normal two button dialog to ask if they really want to continue with the OK Button Value Change event, so if the user presses Continue, don't discard the Mouse Down, and if the user presses Don't Continue, discard the Mouse Down.

My problem comes when they select "Continue". The button toggles, but the OK Button Value Change event does not fire, until you press the mouse again (no matter where, if on the OK button or not). How do I remedy this? I am open to alternative suggestions.

Message Edited by miguelc on 02-19-2008 01:08 PM

[tst]

The easiest thing would be to get rid of the Mouse Down? event and use just the value change event. Make the rest of the code in the event dependent on the result of the first dialog.

By the way, this does seem to be a bug, so I would suggest that you report it.

[GerdW]

Hi Miguel,

interesting behaviour...

I see the same, but with an interesting twist: when running the vi in highlighted mode it runs as expected!
I included a "value (signal) property node, but this doesn't help. It also doesn't help to include a timeout event case...

[miguelc]

Thanks for the responses. This event was to handle three different buttons, so I was trying to avoid duplicating code by placing it in each Value Change event. But maybe I'll have to...

It is interesting that it works in Highlight Mode, there must be some timing issues between the Mouse Down? event and the actual Value Change event.

I've reporte the bug to NI.

Michael

[GerdW]

Hi Miguel,

duplicate code can be converted to a subvi

[Matthew_Kelton]

The problem is that you are losing the mouse up event.  If you click the OK button and just move the mouse over the OK button after you hit continue, you will see it thinks it is pressed.  When you click it again, the mouse up event is recognized, which is what fires the value change since your latching is on the button up.  Because you call a dialog box before you ignore or keep the mouse down event, you've mangled the whole event.  The Mouse Up is probably seen by the dialog box.  When you click Continue, you tell the OK button to keep the mouse down event, but the Mouse Up event was never seen because of the processing.

You don't need to do it the way you are.  As someone elase said, use the Value Change Event, then ask your message.  Have the output wire a case statement input.  So, if you hit continue, then you do the code, if not, then you do nothing.

[tst]

Another option is to put all three value changes into a single event case. Then, build the wires coming out of the control terminals into an array and search that array for a T value. That should tell you which of the buttons was pressed. This assumes that the buttons have a latched mechanical action.

Another way of doing this is to build their references into an array and use the CtlRef output terminal available in the event structure to search that array.

[altenbach]

I am not sure why you think you need to filter and discard the event. (Seem to interfere with the latch action). What is your reasoning?

[tst]

Good point, Matthew. Changing the mechanical action to latch when released fixes this.

[miguelc]

Thank you Matthew for that explanation, it seems sound. My only problem in understanding the behavior now is why after pressing Continue on the dialog box, then clicking anywhere on the Front Panel that the Mouse Up is attibuted to the OK button.

TST and GerdW, thank you for the additional suggestions. I'll probably build a subVI, keep it simple. I'd like to keep the Value Change events seperate as they are fairly different.

Michael