Don't force all LabVIEW windows to the top when one is selected

[User002]

My idea is to have LabVIEW cease and desist it's self-important modal behavior.  Not that I think LabVIEW is anything other than the most important application I run, but I don't think it should force its (many windows') way to the front of the line when I shift focus to a LabVIEW window.  I didn't find any other idea that matched this, but there is this discussion that covers the notion well.

An example case:  When chasing efficiency I frequently have Task Manager open to observe CPU usage when I change front panel controls.  I'll run the .vi and load Task Manager, but when I click on a front panel control ALL the LabVIEW windows come to the front and cover Task Manager:

So, my suggestion is to have only the selected LabVIEW window come to the front.  I get the impression that Ctrl-Tab and Ctrl-e behavior are why LabVIEW controls its own window z-placement, but leaving their function out of it, my suggestion is just to change the modal behavior of LabVIEW windows.

[David_L]

I don't think this idea is at all a duplicate of either of the other two features proposed (however it's linked to the alt-tab behavior).  And I would by no means call it standard windows behavior.  In fact I don't know any other applications that actually act this way and I can think of many examples of other software that behave correctly.  A few that are running on my system right now are Word, Firefox, Evernote, Google Talk, heck even Lotus Notes does this right.  

It's unfortunate that the first page of comments on this idea were negative.  To me this is by far one of the most annoying oddities about the LabVIEW environment.  I feel that this is going to hurt the traction this idea could get as many will see "Duplicate" as the first post and then quickly dismiss it.  Too bad, but Kudos, fairlyFunctional...

[Lavezza]

I remember talking to NI about this years ago. If I remember correctly, it is because LabVIEW is written using the Multiple Document Interface calls in Windows. Most older Windows programs were written that way (and Excel still does it that way if you create a new spreadsheet while working on an existing one). Basically there is a parent Window and a bunch of child windows. LabVIEW makes its parent window transparent to give the illusion of a SDI (Single Document Interface, one window per 'document'). But the illusion fails if you click any LabVIEW window. Since you are really clicking a child window, it will bring the (invisible) parent window to the front. That makes ALL the child windows come to the front. I was told that switch to SDI was non-trivial (although most other older Windows programs have made the change including Word).

BTW, we were asking not because we wanted the LabVIEW IDE to act differently, we wanted our build apps to act differently. But built EXEs inherit the pseudo-SDI hack.

Wikipedia MDI entry

[JKSH]

---

@AristosQueue (NI) wrote:

Interesting. Bluntly, I have no idea how they achieve that effect.

Can you find any non-Microsoft programs that can do that? MS has been known to put hooks into the OS that only their applications can use.

---

I used the Qt framework to create a minimal test program that does this. Only the window that I click/Alt-Tab will be brought to the front; the other windows from the same process stay behind.

Here is the Task Manager output and the full 15-line source code:

#include <QApplication>
#include <QWidget>

int main(int argc, char *argv[])
{
	QApplication app(argc, argv);

	for (int i = 0; i < 5; ++i)
	{
		QWidget* w = new QWidget();
		w->show();
	}

	return app.exec();
}

The source code for the Windows implementation of QWidget (using the official Windows SDK, without secret hooks) is at

http://qt.gitorious.org/qt/qt/source/src/gui/kernel/qwidget_win.cpp

---

@David_L wrote:

It's unfortunate that the first page of comments on this idea were negative.  To me this is by far one of the most annoying oddities about the LabVIEW environment.  I feel that this is going to hurt the traction this idea could get as many will see "Duplicate" as the first post and then quickly dismiss it.  Too bad, but Kudos, fairlyFunctional...

---

Well-said, David. Kudos from me too!

I've been doing full-time work using LabVIEW for over half a year now, and this behaviour still jars me and slows down my workflow. Maybe I'm just slow, but I still can't get used to it...

---

@Lavezza wrote:

I remember talking to NI about this years ago. If I remember correctly, it is because LabVIEW is written using the Multiple Document Interface calls in Windows.

---

Really? I was pretty certain that each MDI program only produces 1 taskbar/alt-tab item, regardless of how many nested windows there are. I don't have any MDI programs on my current computer to check right now though.

[tst]

To quote someone who knows, LV does do its own window management and apparently at least of some that code is "nontrivial". Maybe that helps with understanding why this behavior was never changed.

Personally, I'm not sure I would want this change. While the current behavior is annoying, there is also something to be said for it. I'm voting for this idea because I think it's worth looking into to see how it actually behaves. I personally don't think I would care that much either way.

[StephenB]

This is very annoying. I typically have many many application windows open including many browser windows and tabs... But LV just insits on putting all my projects, libraries, VIs and classes on top whenever I click any of them. Makes my multi monitor setup not as useful

[AristosQueue (NI)]

StephenB: On the flip side, the vast majority of apps do not have interconnections between windows. For example, if I am editing LabVIEW, I frequently use both the VI diagram and the project tree, back and forth. I note that an app like Adobe Photoshop may not pull all of its windows forward, but it does pull all of its tool windows and palette windows forward regardless of which image window you bring forward (they aren't floaters because there is only one copy of the tools windows regardless of how many images you have open).

Everyone:

Let's assume there is a way to sever the requirement for LabVIEW to bring *all* windows forward. Should it continue to bring *some* windows forward other than the one you tabbed to? For example, should bringing the diagram also bring the panel forward since they're the same document? Should we bring the project window forward for any VI? The probe watch window certainly seems like one that should come forward regardless of which VI.

Thoughts?

[User002]

I agree that the probe watch window is certainly one to bring forward.  For the others there are shortcut keys that I hit without thinking to go to the project explorer or to switch between the front panel and block diagram.  I would prefer the FP/BD not move together because there are times where I want to compare one or the other with a requirements document or browser window.  In Photoshop the tool and palette windows are roughly equivalent to the palette in LabVIEW, so other than a pinned palette or the probe window I don't really see a case for anything else.

[Darin.K]

This type of question arises around here a lot, and my answer is always the same:  You never go wrong doing precisely what the user asked, no more, no less.  Click a window bring it forward, not its buddies. The Probe Watch Window is a special wannabe floater so it makes sense to let it do its thing.

[intvsteve]

LabVIEW does not use any MDI-related APIs to get this behavior. The reason the windows behave as they do is that they all have a common owner window. This implementation decision was made long ago, and at the time, this behavior was intended. If memory serves, back then, we replicated the behavior of the Mac (early 90's). As we didn't need to do anything special to get the behavior on the Mac, as the OS changed its stance regarding this sort of behavior, LabVIEW's behavior changed as well. Not so for Windows.

An example that illustrates similar behavior to LabVIEW's is what you see in Visual Studio when you 'tear out' utility windows. These are owned by the main Visual Studio window. so if you click in one of these utlity windows, the entire Visual Studio editor comes to the front.

As to the feasibility of this feature, the devil is in the details. This specific request is superficially unrelated to ones that others have claimed this request to be a duplicate of - i.e. the various Alt+Tab-related items. However, modifying window ownership will have side effects in other areas of window behavior, such as Alt+Tab, floating windows (the palettes) and modality.

[crossrulz]

Context Help, Tools Palette, Probe Window, and any other pinned palettes are the ones I think should come forward as well.