LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Mouse clicks send app to crazy land

I have a multi-threaded app with two main windows. One is the data display / main user interface event handler. The other is a seperate window with nothing but the menu bar--basically categorized commands that may be executed independent of what the main user interface is doing. This way I can move the commands around, hide them, etc--they are seperate.

From the user interface I am running a script. At first the sub-vi that ran scripts was a modal 'Cancel' button to end the script and return to the user interface. The modal property kept the user from doing anything with the user-interface while the script was executing. Perfect. The problem is, it also kept the user from accessing the command window. So I changed the scri
pt from a modal dialog box to a non-modal pop-up window that i set to Always-on-Top. This allows access to the command window and keeps the 'Cancel' button on top so it won't disappear behind the user interface if the main window gets clicked. Also, the user interface remains locked out because the script sub-vi is called from the user interface event handler.

The problem I have is that clicking on the main user interface (for example, selecting a different tab to view) while the 'Cancel' button dialog box is visible, does nothing. When the dialog box exits however, all of the clicks done previously (which you'd think would have been forgotten), get propogated. The application goes haywire momentarily trying to change and update things. If you clicked five different tabs while the dialog box was open, it would do nothing, then all of a sudden (when the dialog box exits), flip rapidly between the five different tabs selected, as fast as possible.

Is there any way to cancel
or ignore these mouse click events that get sent to the main user interface? Is this a problem with the windows Always-on-Top setting?
0 Kudos
Message 1 of 6
(2,614 Views)
Sorry for the double post (internet explorer rrrrrr....)

I have also found that I can click in a text control on the main user interface, type a bunch of text while the 'Cancel' button is visible (nothing happens--no text appears)... and as with selecting other events, once the dialog box is gone the main user interface processess the click to the text box and all keystrokes, effectively doing a bunch of things it shouldn't.
0 Kudos
Message 2 of 6
(2,614 Views)
> I have also found that I can click in a text control on the main user
> interface, type a bunch of text while the 'Cancel' button is visible
> (nothing happens--no text appears)... and as with selecting other
> events, once the dialog box is gone the main user interface processess
> the click to the text box and all keystrokes, effectively doing a
> bunch of things it shouldn't.

I believe that your main VI's diagram has entered an event structure and
has not left yet. This means that by default, the UI is locked waiting
for your diagram response to complete, and is queuing raw events until
that happens.

You could change the behavior to be a little better by invoking your
stay-on-top dialog outside the event structure, or by disabling locking

for handling that particular event. But, that it sounds like you want
your main window to not only be unlocked, but to be executing. At the
moment, it is waiting for the subVI call to complete.

There are several ways to architect your program to do this, but the
basic strategy is to keep your look that does event handling for the
main window from waiting on subVI calls to your floater to return. You
can do this by making one or more parallel loops that are signaled to
carry out the action, or you can use the VI server to launch up parallel
tasks. Either way, be prepared for your state logic to get more
complicated due to the fact you have parallel UI tasks going on.

Greg McKaskle
0 Kudos
Message 3 of 6
(2,614 Views)
> I believe that your main VI's diagram has entered an event structure and
> has not left yet. This means that by default, the UI is locked waiting
> for your diagram response to complete, and is queuing raw events until
> that happens.

This description is correct... the main VI calls the stay-on-top subvi from an event handler. However the program's behavior is the same when invoking the stay-on-top subvi from outside the handler (passing an argument to a case statement that runs the subvi. Behavior is also the same when disabling locking for that event. I do want the main vi to be locked when this subvi is called so the user can't do anything else--change tabs, type in boxes, click things, etc. Do you have any other ideas of how to mak
e sure it does not queue raw events until the on-top subvi closes? I don't want the events processed when the subvi is complete, just discarded.
0 Kudos
Message 4 of 6
(2,614 Views)
> This description is correct... the main VI calls the stay-on-top subvi
> from an event handler. However the program's behavior is the same
> when invoking the stay-on-top subvi from outside the handler (passing
> an argument to a case statement that runs the subvi. Behavior is also
> the same when disabling locking for that event. I do want the main vi
> to be locked when this subvi is called so the user can't do anything
> else--change tabs, type in boxes, click things, etc. Do you have any
> other ideas of how to make sure it does not queue raw events until the
> on-top subvi closes? I don't want the events processed when the subvi
> is complete, just discarded.

What you describe isn't what I'd expect. Panels are only locke
d during
an event structure responding to an event. They are unlocked at the
right edge of the structure, and this is done optionally.

If you really do want to dialog to block events to the main window, then
you can make the subVI modal. I reread the original post, and it isn't
clear why you are moving from modal to floating. If you wish for just
some of the UI to be blocked, use the Enable/Disable property to disable
the controls. One easy way to disable lots of controls is to place them
inside of a tab and disable the tab control.

Greg McKaskle
0 Kudos
Message 5 of 6
(2,614 Views)
> "This is certainly occuring because of the "Always on Top" selection. However, there is one
> option you have here. You could try using Dynamic Events. They're new to LabVIEW 7.0.
> You can actually unregister a particular event (tab changed) and have it only trigger when you
> want. For instance, you could unregister this right before the cancel window comes up. Then, if
> the user clicks the tabs, since this event is unregistered, they will not be tallied. Then, when you
> get back to that window, there will be no events stored up so nothing should happen."

Comment above was posted by JRA on the inadvertant second posting by the same name. It sounds like the solution to my problem although I don't have version 7 ye
t to try it with.

> it isn't clear why you are moving from modal to floating.

The reason I am changing the dialog from modal to floating is because there are two windows the program normally has open, one of which I want to work, the other which I want disabled. A modal box will not allow the user to access the main user interface window, but it will also not allow the user to access the command window. The main window needs to be completely disabled while the command window will allow the user to select items from the menu and execute code associated with those items. When the main window executing a subvi that is always on top, it appears to be working in the manner I would like it to because the rest of the user interface is not accessible while the command menu is, however, unknown to the user, any events that take place in the main window and don't appear to be doing anything are actually being queued--they are processed in full once the execution of the subvi is complet
e. I hope that explains things a little better--it's kind of a confusing problem.

Thanks for your post... I'm guessing I'm going to have to wait for the purchase paperwork to go through for version 7.
0 Kudos
Message 6 of 6
(2,614 Views)