Prevent restoring minimized Labview windows when opening another vi file

[Novgorod]

---

@JÞB wrote:

Potentially embarrassing question.

Did you try single clicking?

Note: You didn't demonstrate opening files from Windows Explorer....you activated Shortcuts on your VM desktop 

---

Uhm, how familiar are you with Windows? 🙂 Single-clicking selects a file, double-clicking "executes" it (or in case of non-executables opens the file with the program registered for its extension). I think there's some weird registry setting from the Win95/98 Explorer times to "execute" a file on a single click, but that would be extremely impractical. However, pressing "enter" after selecting a file in Explorer does the same thing as a double-click on it - with the exact same window restore behavior.

The test files in my demo on the desktop were the actual files, not shortcuts to the files elsewhere. The Windows desktop functions exactly like a folder in Windows Explorer (it's part of the Explorer process and handles file interactions the same way as in any other Explorer window) and the "restore bug" happens identically if the files are in another folder and I navigate there in a separate Explorer window and double-click (or press enter on) the vi.

[Novgorod]

If altenbach is confirming it, that means I'm not hallucinating 🙂 ... I also experience the exact same behavior he talks about when interacting with non-Labview windows, but I constrained my issue here to the Labview application itself and its internal window management for simplicity. If this can get solved, it may also inadvertently solve the issue with windows from other applications.

[softball]

Hi

I can confirm your observations too.

I see this as unfinished work from the developers of LabVIEW.

The problem could have been solved ( easily ? ) if more work had been put into the All Windows panel :

There should have been a Hide button too, next to the Show button. Just for a start. More fancy options could have been added too, like window front panel + block diagram pair grouping and and ..

But I guess this is all too late to be fixed. Elvis has left the building.

Regards

PS :

MGI once made some work, https://www.mooregoodideas.com/mgi-library/panel-manager/dotnet-panels/

[thols]

---

@altenbach wrote:

...If I open a Vi from window explorer and have many VIs already open, all with their diagram front panel windows minimized, at least one of the existing minimized windows gets restored too for no obvious reason.

---

I cannot recreate the issue in the video the OP posted, but I can confirm altenbachs observation. 

And to add to altebach's window whack-a-mole, LabVIEW sometimes decides to shuffle the z-order of the windows, especially when switching to other apps, making it even harder to find the right window. Some years ago, that shuffling could continue indefinitely but that seems to be fixed (or I don't trigger it anymore for some reason)

[Andrey_Dmitriev]

---

@Novgorod wrote:

If altenbach is confirming it, that means I'm not hallucinating 🙂 ... I also experience the exact same behavior he talks about when interacting with non-Labview windows, but I constrained my issue here to the Labview application itself and its internal window management for simplicity. If this can get solved, it may also inadvertently solve the issue with windows from other applications.

---

Yes, this is why I always have three monitors on my desk. In the middle, I have a 30-inch DELL U3011 (2560x1600), and on the sides, I have 20-inch monitors in vertical orientation (the right is a DELL 2007 (1200x1600), and the left is an Eizo RadiForce RX380 (1536x2048) — as I need a 10-bit monitor for x-ray images). It's better to have the same pixel pitch and vertical resolution on all monitors.

All three are connected to an NVidia RTX A2000. Some time ago, I tried a huge single 40-inch DELL, but it wasn't as good because no desktop manager can correctly emulate multiple monitors with proper handling of maximization behavior. Three monitors are pretty convenient — I can move project, debug, and other windows to the sides, and they will not overlap with LabVIEW, which remains in the middle.

[Frozen]

---

@Novgorod wrote:

---

@JÞB wrote:

Can anyone reproduce or confirm this behavior? I observe it all the time on many different PCs and Windows versions since "forever" (years). It's just a minor nuisance so I didn't pay much attention to it and can't tell in which Labview or Windows version it really started, but it would be great to override this window restore behavior...

---

I don't know what JÞB is going on about. LV has always this for me for as long as I can remember. I just assumed it was part of how LV worked. It is rather annoying have the extra LV window pop open. I had to double check your comment about double-clicking an already open vi... and sure enough, up comes an addition LV window 😒

Has anyone posted something on Idea Exchange yet?

[Andrey_Dmitriev]

---

@Frozen wrote:

---

@Novgorod wrote:

---

@JÞB wrote:

Can anyone reproduce or confirm this behavior? I observe it all the time on many different PCs and Windows versions since "forever" (years). It's just a minor nuisance so I didn't pay much attention to it and can't tell in which Labview or Windows version it really started, but it would be great to override this window restore behavior...

---

I don't know what JÞB is going on about. LV has always this for me for as long as I can remember. I just assumed it was part of how LV worked. It is rather annoying have the extra LV window pop open. I had to double check your comment about double-clicking an already open vi... and sure enough, up comes an addition LV window 😒

Has anyone posted something on Idea Exchange yet?

---

I took another look and I think we can classify this as a real LabVIEW issue, rather than a topic for Idea Exchange. It is not Windows; it is LabVIEW.

Let me explain.

When a user clicks on a file on the desktop, Windows sends a message (WM_COMMAND or similar) with the path of the double-clicked file to the app. So far, so good. Somewhere in LabVIEW's WinMain loop, we have a handler that receives this message. The issue is that LabVIEW has a list of windows of currently active VIs, and the FIRST one in the list will always be opened, preceeding the target VI. If the target VI is the same as the VI that is already first in the list, then only one window will be opened as expected. But if they are different, then both will be opened — the first one in the list AND the VI that the user clicked on. Another important point is that this list is always modified when a VI is minimized, and the minimized VI is placed at the END of this list. As a result, two VIs may be opened or not depending on the order in which the VIs were minimized. On double-click, the newly opened VI is placed at the top of that list. That's it.

Let me illustrate.

I have three VIs on the desktop and will open them in the order 3, 2, 1:

The windows are arranged in the list as 1, 2, 3, because every time a newly opened VI is placed on top, and the "Test 1" was opened last, hence this order.

Now I will minimize the first VI, then the second. Look what happens to that list:

When the first VI is minimized, the order changes to 2, 3, 1, and when the second is minimized, it changes to 3, 1, 2 (again — minimized VIs are placed at the end).

Now if I minimize the last third VI, the order will be 1, 2, 3.

And now the issue — if I click on VI 2 or 3, then this VI will be opened TOGETHER with 1 (which I don't want to see) because 1 is the first in the list. Let me demonstrate:

Obviously, if I close the VIs in the order 1, 2, 3, then open the first VI with a double-click, only this one will be opened as expected and no other annoying windows will be opened. Let me show this as well:

So, finally, this issue — if you get two opened windows depends on the order in which you minimized the windows. For example, if I want to get only VI 2 opened, then it needs to be minimized first, then the other two, and you will not have such a window:

But if the topmost VI in the list does not match the clicked VI, then you have both. For example, I can easily get 2 and 3 together, this is a problem:

It is an issue with how the double-click message is handled inside LabVIEW, seems to be nothing related to Windows. In my humble opinion, NI can fix it. You can also easily recognize in the last gif — when the "wrong" VI pops up, it always comes first, and then shortly after, the "correct one" is displayed. This delay is clearly recognizable.

[pincpanter]

Uhm, how familiar are you with Windows? 🙂 Single-clicking selects a file, double-clicking "executes" it (or in case of non-executables opens the file with the program registered for its extension). I think there's some weird registry setting from the Win95/98 Explorer times to "execute" a file on a single click, but that would be extremely impractical. However, pressing "enter" after selecting a file in Explorer does the same thing as a double-click on it - with the exact same window restore behavior.

---

No weird registry setting, just a click in the Folder options. But I agree that this would be impractical.

[Novgorod]

---

@Andrey_Dmitriev wrote:

---

It is an issue with how the double-click message is handled inside LabVIEW, seems to be nothing related to Windows. In my humble opinion, NI can fix it.

---

Nice research, I wasn't aware of the internal window sequence in Labview's window manager and its strange rules. That would explain the strange behavior when you double-click an already open vi. It also means that if you double-click on a vi that is not (yet) in Labview's window list, it will always restore the first window that's already in the list (if any) and then add the double-clicked vi to the list at the first spot and open its window.

So the solution to both issues should be a "simple" change of sequence within the double-click/open message handler, i.e. first add the double-clicked vi to the window list (or move it to the first position if it was already open) and only then open/restore the first window in the list, right? Oh well, maybe we mere mortals may dream that after 20+ years someone in the NI castle far above the clouds would have the mercy to change one line of code...

[Andrey_Dmitriev]

Ah, I forgot about the trivial case: if the VI is not opened at all, then double-clicking will open it, and again, it will be the first one from the list.

Same issue.

Well, hopefully NI will fix it. But to be honest, not many users open VIs directly from Explorer; usually, they are organized in projects and libraries. I usually open projects that way and only very seldom open individual VIs, but it depends.

An own fix is also theoretically possible, but quite complicated. I see two major possibilities: one is to set a hook on the Windows messages related to double-clicking and restoring (something like WM_SHOWWINDOW should be used inside), then “filter out” inappropriate VIs and keep only the double-clicked one restored. Another possible approach is reverse engineering LabVIEW (which is generally a license violation), locating this logic in the assembly (I don’t think plain VIs are involved here), and correcting it (either in the executable or just in memory). Both ways are interesting from a technical point of view, as a kind of brain training.