Make LabVIEW dialogs non-modal.

[jdeguire]

There have been plenty of times where I'll be doing something inside a LabVIEW editor dialog (like the Properties dialog for a control), but want to quickly look at another block diagram or probe window.  I can't, however, because the dialog I'm in is modal, meaning that it won't allow window focus to go anywhere else.  So then I have to close the window, go find whatever it was I was looking for, and then re-open the window.  Not a huge deal, but it bugs me everytime I do it.

Usually, this happens to me when I'm in a Properties dialog and need to look at a probe from the Probe Watch Window.  I'd like to be able to switch to the probe I need without having to close the Properties dialog. 

Therefore, I would like dialog windows (including the Icon Editor, which is also modal for some strange reason) to be non-modal.  So that we don't forget about them, the windows could still be top-level so that they are always above all of our other windows.

[Intaris]

In principle I agree, but I wonder about the implementation details....

[jdeguire]

I was wondering about that as well.  Maybe they are modal to prevent you from opening up multiple dialogs, which would cause other problems.

[JackDunaway]

This is a broad Idea that has implications, but I certainly give Kudos in order to re-evaluate the sometimes unecessary use of modals in the IDE. Although some need to remain modal to prevent user action on other windows, many could be "demoted" to floating to provide a more interactable (word?) IDE.

Here are more modal links:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-Build-Error-Window-Floating-Not-Modal/idi-p/98388...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/A-Better-quot-List-Unsaved-Changes-quot/idi-p/1088011

[Manzolli]

I agree, modals windows bugs me sometimes, not only in LabVIEW. Save window is a good example of a modal window. Sometimes it which forces me to cancel the save process in order to find out important information to put in the file name. The main purpose of modals is to guarantee that the user close the window to continue, to assure that there are no pending decisions. Allowing a non-modal behavior a window can be left behind others. How the system will deal with that? Like pointed by The J, many open windows can be a mess...

[WG-]

You know you can edit this behavoir with the property "Front Panel Window Behavoir"?

[RavensFan]

Wouter,

They aren't talking about dialogs you'd be making as a programmer, but dialogs that the LabVIEW development environment pops up such as the save dialog or the properties dialog.

[Ben_Phillips]

I agree in concept, but I think the implementation would raise quite a few subtle issues that would become even more annoying.  Floating windows can get sent behind what you're seeing, I'm not entirely sure how it happens, but I know it does.  For example, it often happens when I open a CSV file, which I have set to open in OpenOffice, the import window somehow gets set behind most of my active windows.  

I've "opened" the file, but it hasn't come to the front.  What happened?  Turns out, I have to go back to the desktop, then click in the Windows task bar on Open Office, and THEN the import window comes back out on top (there's other ways to get the window where you can use it, all equally unintuitive until you get used to it).

Now bless their hearts, I think they perhaps make it non-modal in order to not assume that OpenOffice is the most important program on your computer, and just hijack at will.

This might not be completely correct in my blame association.  Windows xp/vis/7 modal is not the same as LV modal, even if similar.  

I just know that having played around with default/floating/modal window settings a lot, in fact quite a bit more than I ever wanted to, that it's far less trivial than it seems at first.

This comes up quite a bit if you inherit legacy code where someone used modals for convenience to make sure the latest query is the only one you can answer.  And it does work well for their prototype ... the latest modal window shown always trumps all others, easy to implement at first ... but it can be a problem when you want to build on top of that, use an old program and integrate it with an 'interface' into something larger.

But just in case you think I'm fully contradicting you, I do agree that modals can be incredibly irritating.

[Ben_Phillips]

What I meant about modals in legacy code, is where a modal is brought on top of a modal, and then another modal is brought on top of all that, repeat 3x.

It's more common than you might think, if you haven't seen it.  I've seen some pretty amazing programs that do this.  

That is rather tough to make work correctly if you try to unharness the app from using modals every time you want to really center the user's attention on something.

[JackDunaway]

Great link from AQ (originally spotted here) with guidelines for modal vs. modeless windows. I think implementing the following two guidelines would fulfill the spirit of this Idea and make several IDE tools easier to use:

• Use [modeless dialog boxes] for frequent, repetitive, on-going tasks
• Use [modal dialog boxes] for critical or infrequent, one-off tasks that require completion before continuing.

[AristosQueue (NI)]

Jack: The two key areas to be concerned about, as I see it, are Undo and window cloning.

For undo, if I open a modeless block diagram, a modeless Control Property page, a modeless Icon Editor, and a modeless Event Structure configuration, and then start making changes in all four windows at will, when I hit Undo, is it confusing if changes are being made across multiple windows? We already mix the undo stack for FP and BD, so maybe this isn't a problem.

For window cloning, if I have two event structures and I open the configuration dialog for both of them simultaneously, how do we maintain the association that "this window goes to this structure and this other window goes to that other structure"?

I'm not saying that either of these are insurmountable, just that they would be the "implementation details" that would warrant thinking about.