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