LabVIEW.exe Command-Line Argument to Open Minimized/Memory

[d.w.b]

Provide a new command line option to open the VI specified on the command line automatically minimized (/MIN) or hidden, i.e. just in memory (/MEM). When I want to research something in a project, I open many top-level VIs from the command line which takes a considerable amount of time. While they are loading I should be able to work on something else but LabVIEW keeps opening the windows on top of all other applications. Neither cmd.exe's start /MIN a.vi nor start /MIN LabVIEW.exe a.vi minimizes it. See current arguments here: https://www.ni.com/docs/en-US/bundle/labview/page/lvhowto/lv_defined_args.html

Consider that a related idea had 334 kudos but was declined for NI-convenience. If LabVIEW did that this wouldn't be needed: "Don't force all LabVIEW windows to the top when one is selected" - https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Don-t-force-all-LabVIEW-windows-to-the-top-when-one-i...

[fefepeto_kb]

I think that this idea is great and a possible source of issues at the same time.

It is great when you did not modify any of the UI properties in the VI property window.

A possible threat when you set the window as modal.

I don't say it would be impossible to detect whether a VI has some UI options, and ignore the argument but that would make the behavior inconsistent.

I suggest to try working this around by implementing a library that hides the window at the beginning of the execution using invoke nodes for the VI based on the arguments. Better yet, have a new custom operation that does this for the called VI automatically, even without an extra argument.

[d.w.b]

I don't think that is an issue because the VI will be opened in edit mode thus will not be model at that time. I suppose fefepeto_kb's concern was that if a VI has custom Window Appearance property set to modal and that VI is opened from the command line (e.g. labview.exe /MIN modal.vi) that it will be model when minimized and prevent access to any other window.

[fefepeto_kb]

Where I was going to with my comment: if a VI is set to run when opened, and is modal, but the front panel isn't shown then the whole environment becomes unresponsive. Not a great user experience. It might be a corner case.

Maybe another option to consider is a launch VI for all the VIs to be opened, which would open them up and minimize them immediately, although that would also pop the window up for a moment.

On the other hand, when I have another application open in front of LabVIEW, the newly opened VIs don't interfere with whatever I do if opened from a launched project. The splash screen does, but the rest of the windows open up in the background just normally.

[d.w.b]

fefepeto_kb, thanks for clarifying. You bring up a good point yet still does not seem too difficult to resolve. The /MIN option would simply be overruled by such VI properties. Modal VIs currently override the "Allow user to minimize window" checkbox; even if checked the user cannot minimize because the VI's minimize button is disabled. Another scenario with run when shown would be the "Allow user to minimize window" being unchecked. /MIN would simply be ignored for these states.

I would be equally satisfied without a /MIN with a /MEM (load into memory, i.e. hidden) which would ignore the "run when shown", because it is not being shown!

[fefepeto_kb]

I see your points, but maybe this interface could help as well: Creating Custom Command Line Operations - NI.

It allows creating custom operations, like an open VI, and adding arguments like -min, or -minimized.

I mean, it would be a nicer to use the more modern command line interface, and the new operation could be extended very easily, even by end customers.

I think if we are suggesting a solution, this would be an option that can have more use cases. This is just an opinion.

[wiebe@CARYA]

You can make a VI that catches the Application OS Document Open? event.

VIs that are opened through explorer or the command line should trigger that event.

If you open the path with an Open VI Reference, and discard the event, you can open the VIs any way you want.

This gives the control to your VI, and it's not a solution of the proposed idea (where the behavior is controlled by the command line). Giving a command line this power could be dangerous, as malicious code code be executed without the user knowing (which is a somewhat weak argument, as the VI could hide itself right after it starts).

The benefit of using the event is that it will work in executables too. Not sure if a CLI solution will.

Because you're opening the VI by reference, you can potentially set input values as well. So you can set e.g. an input class to give the test VI access to application data.

[fefepeto_kb]

If you open the path with an Open VI Reference, and discard the event, you can open the VIs any way you want.

I think that's the point of the CLI interface, that you can create your own operation that allows you to handle the commands the way your want. It allows you to check the VI that will be opened, and also to change it's settings before it executes. Don't forget that the CLI uses TCP VI Server interface, which already limits some of the settings that would be dangerous.

which is a somewhat weak argument, as the VI could hide itself right after it starts

You are right here. If someone has enough access rights to the environment to start an application it's all done. You cannot really do anything against that anymore.

The benefit of using the event is that it will work in executables too. Not sure if a CLI solution will.

The CLI solution won't, it's specific for development environment, but my understanding is, that the development environment usage is the issue here.

Because you're opening the VI by reference, you can potentially set input values as well. So you can set e.g. an input class to give the test VI access to application data.

It totally depends on your implementation. If you created the operation to only open the VI as is, then it won't be a problem. Also, from CMD you cannot change the input. Additionally, if you want to run a VI, there is already a built in operation for that: Predefined Command Line Operations - NI. It does not allow other input manipulation than the CLI arguments. If someone can put a VI that changes the inputs of your VI that means they had access to your files, and access to launch applications. You are in a bad security state since a long time 😄. If these cases are really a concern, I think the machine shall be disconnected from the internet, be in a closed room with limited access and the login shall be limited to a few people too. It that doesn't save you from malicious code nothing will.

[wiebe@CARYA]

I know the limitations of CLI, I was offering solutions...