Prevent restoring minimized Labview windows when opening another vi file

[tst]

---

@Novgorod wrote:

---

---

...but certainly no comparison to native support.

---

No, but you can certainly sometimes get some useful tools from working on your own. Here's a crude version (LV 2015), just because I thought it was interesting as a thought experiment. Obviously, the code is not production level and this is unusable as-is, but it does show how such interactions might work. I think that the main improvement over the multiple windows might come more from merging the FP and BD into a single line rather than from the fact that it's in a single window and this could probably also be managed similarly with multiple open windows rather than with everything in the same window. Another usability improvement which immediately comes to mind is to add a search/filter to allow getting to VIs quickly, but I'm sure there are many others.

[Novgorod]

---

@tst wrote:

No, but you can certainly sometimes get some useful tools from working on your own.

---

Definitely. It's just about how much pain you can tolerate before spending your own time and resources on quality-of-life things 😉.. The concept in the demo is quite neat though. I wonder if anyone has already made a proper "editor" based on that - surely I can't be the only one who would find that quite useful...

[Andrey_Dmitriev]

---

@Novgorod wrote:

---

@Andrey_Dmitriev wrote:

---

Anyway, let’s take everything into our own hands. The idea is simple: I’ll replace the «default» LabVIEW launcher with my own. This will also help me in the future to launch the correct LabVIEW

---

Making your own "class handler" for the .vi file type is clever, also the version handling part (though there's more confusion to deal with the 32bit vs. 64bit version of the same major LV version since a vi has no "bitness" and can be opened with both). However, I'm not quite understanding how calling Labview from the external helper tool (instead of through the Windows shell) fixes the window restore bug. I don't know much about Rust but it looks like your helper is calling the Labview executable from the command line with the double-clicked vi as an argument - how is that different than what Windows does when you double-click the vi (apart from choosing the correct LV version)?

---

I’m also not sure — this is just a “side effect” of my “solution”. Perhaps opening a process in an already running application works differently, and some messages are sent. This needs to be investigated and traced more deeply. As I often say, any observed behavior has a rational explanation; there must be a reason, of course.

I think I’ll solve the 32/64-bit issue in a very simple way — by placing some tags near the project files or by keeping a list of the last opened VIs with their specific target versions. Rust is not “special”-WinAPI is WinAPI. This can be done in pure LabVIEW as well, but it would add a noticeable delay to the launch, as well as some additional code to achieve a “headless app.” The Rust-based app is relatively lightweight and better suitable for this (in my opinion), this can be easily done in C/C++ as well.

[zou]

---

@altenbach wrote:

Similarly, all LabVIEW windows are somewhat entangled and don't mesh well with the the handling by the OS. I often bump into the following maybe related problem and this is the direct cause why I often have minimized LabVIEW panels during development. I might have many LabVIEW windows open but not minimized and am working on a small diagram where I try to implement some math. For that I might have a Wikipedia web page containing the formula, so I need to go back and forth and would like to have both windows (panel & browser) next to each other. The problem is that as soon as I operate on the diagram, all other LabVIEW windows will move forwards, covering the browser window and obscuring my view. Now the whack-a-mole starts, where I need to minimize all other LabVIEW windows in order to keep the browser in view when going back and forth between the diagram under constructions and the browser window. Super annoying for many decades already!

---

That's expected Windows behavior.  All windows in the active process are in the front of inactive process.

If it's super annoying, you can use Web Browser.ctl in .NET & ActiveX to create your own browser in LabVIEW.

[rolfk]

---

@Andrey_Dmitriev wrote:

---

---

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.

---

Actually, the Windows Shell does not send a WM_COMMAND but rather a good ol' DDE message, just as it always did in Windows 3.0 days already! Newer Windows Shells support other means such as shell extension handlers, etc, in addition to DDE, but LabVIEW still has a DDE interface built in under Windows that can receive such events.

Basically when the according file entry has a "ddeexec" entry, the shell tries to locate the specified DDE service and if it is registered (aka running) it sends the according command to that service. If the DDE service is not registered (the application is not running), the according command line is executed instead.

Other alternatives that the shell supports are so called shell extension hooks. That are basically COM DLLs registered for the according file entry that are then instantiated and called through their COM factory. COM is "Component Object Model" the basic building technology of OLE and Active X, but not equal to them. 

[rolfk]

---

@Andrey_Dmitriev wrote:

---

---

I’m also not sure — this is just a “side effect” of my “solution”. Perhaps opening a process in an already running application works differently, and some messages are sent. This needs to be investigated and traced more deeply. As I often say, any observed behavior has a rational explanation; there must be a reason, of course.

I think I’ll solve the 32/64-bit issue in a very simple way — by placing some tags near the project files or by keeping a list of the last opened VIs with their specific target versions. Rust is not “special”-WinAPI is WinAPI. This can be done in pure LabVIEW as well, but it would add a noticeable delay to the launch, as well as some additional code to achieve a “headless app.” The Rust-based app is relatively lightweight and better suitable for this (in my opinion), this can be easily done in C/C++ as well.

---

Actually, when you execute LabVIEW from the command line and don't have the ini file setting "allowmultipleinstances = TRUE" LabVIEW will attempt to connect to an already running instance of itself through DDE by attempting to connect to it and if that is successful it will pass the command line to that DDE service and terminate itself.