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.

[fabric]

Another vote to treat the FP and BD as separate entities... And I agree with crossrulz: Palettes and debug windows should always float on top when any LV window is frontmost.

[Intaris]

I add my vote for Palettes and debug windows always floating with whichever Window has actually been activated.  As to FP and BD separately, I don't really mind.  Ctrl-E is pressed rather quickly.

[AristosQueue (NI)]

I asked intvsteve to chime in on this thread (see his post four previous) ... he's got the most expertise in the LabVIEW windowing system of anyone on the LV R&D team.

[StephenB]

Thanks

I agree on palettes, context help, and probe watch window. To be clear, projects and libraries and classes should not come to front. I commonly manage many of them simultaneously so it would be quite annoying to keep that.

LabVIEW programmers commonly have spec sheets up or requirements documents while they program... So its nice to keep those up

[intvsteve]

Palettes, Context Help, and other floating windows operate using a different mechanism than panels and diagrams, so at least that aspect of such a feature should not require additional effort.

[tomlawton]

This is (one part) of the reason that I choose to do as much code dev as I can in Mac LabVIEW, where windows layer individually, rather than per-application. Then, at the last minute, when I have to debug DAQ, I move to my Windows VM, and get angry...

[Blokk]

Agree, this is very annoying behaviour!

[saratoga]

I've been complaining to NI for a decade now about this.  They don't care.  I did find a great solution though:

Stopped using Labview.  Would recommend.

[X.]

Check out the Next Gen Preview.

While it has its share of terrible design choices (such as no way to have separate windows for front panel and diagram), at least (after some effort to get separate windows for different VIs in the first place) the individual windows act autonomously.

To apply for access to the LabVIEW Next Generation Technology Preview go to this page.
A current Standard Service Program contract is necessary.

[marshaul]

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)...

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.

Agreed, and this is probably one of the worst aspects of NI in general and the idea exchange in particular. LabView in many cases behaves completely contrary to current established paradigms for user interface, to the point of conflicting with established workflows and generally being grossly nonstandard. In short, it's a huge PITA to work with, with the vast majority of issues relating to lazy and/or archaic UI design practices which NI refuses to address, or even consider.

When a user points this out, instead of seeking to address the complaints, the immediate and first response is inevitably a desperate flood of "oh, well, actually, this is a duplicate of this, that, and the other (which is almost invariably not actually true), so clearly you don't know what you're talking about and you can be safely ignored just as we ignored those other guys and their actually-unrelated ideas".

And then, having successfully derailed the idea threat at the start, even once it's demonstrated that the idea is not a duplicate, there will be another desperate flood of "oh, well, this is impossible, and you shouldn't want it anyway, and besides it's standard" responses. And, finally, when users demonstrate that it is, indeed, possible and desirable and that the existing behavior is nonstandard, we simply get a decade of crickets.

I have to say, while I have come to learn to appreciate the G language itself (my background is embedded C, so it was not love at first sight), the development environment is a nonstarter at this point, and I only use it because of legacy code requirements. It's impossible to imagine ever choosing it for a new project in the future. I must agree with this user:

---

@User002

I've been complaining to NI for a decade now about this.  They don't care.  I did find a great solution though:

Stopped using Labview.  Would recommend.

---