LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
dafemec

Don't force all optional arguments in Invoke nodes to be shown

Status: New

Invoke nodes can have lots of optional arguments, resulting in their taking up a lot of vertical space.  I would like to recommend that the arguments portion of Invoke nodes be resizeable, allowing the developer to select the optional arguments to be displayed on the block diagram and, hence, have more control over the layout of the block diagram.

 

Consider the Save-As Invoke node from Microsoft Word:

 

Current Microsoft Word Save-As Invoke Node

 

which gets longer with each new version of Word.

 

Now imagine being able to show just the optional arguments that are needed:

 

Just the Optional Arguments that are Needed

 

And, as an added bonus, this Invoke node would not break when the VI is opened in a development environment that has a different version of Word with the same exposed optional arguments.

10 Comments
JackDunaway
Trusted Enthusiast

How about selecting/rearranging optional parameters à la Express VI?

 

InvokeNodeOptionalParameters.png

dafemec
Member

That could work!

AristosQueue (NI)
NI Employee (retired)

To the best of my knowledge, the _Document class is a third party API, and those are not optional parameters in that API. The document class is defined by MS and if you were coding in any .NET language, you'd have to specify all those parameters. This is a request that would have to go to Microsoft to be fixed.

 

Your request for Invoke nodes in general to be able to leave out optional parameters is something LV could look into.

 

Having said that, try dropping any subVI node, then pop up on the node and turn off the menu option "View As Icon". Now your node looks a lot like a yellow express VI, with labeled terminals, a lot like an invoke node. You can grow and shrink it. Terminals aren't hidden when you shrink it, but they are moved to a more condensed, unlabeled form. What if we enabled this sort of terminal minimization for invoke nodes? (It still wouldn't help on the _Document class since those would still be required terminals.)

dafemec
Member

Yes, the _Document class is a third-party API, but the items with gray backgrounds are optional.  In a text-based language, I would only need to include in a function call the optional arguments I needed.  I am asking for the same ability here.  LabVIEW knows the arguments are optional, and the formatting of the Invoke node is clearly in LabVIEW's hands, so I think the change can be made.  Lastly, my apologies, but I don't understand the relevance of your point about using "View As Icon"; yes, I understand I can do that with a subVI node, but this does not work with an Invoke node.

AristosQueue (NI)
NI Employee (retired)

> yes, I understand I can do that with a subVI node, but this does not work with an Invoke node.

 

I was asking if that model would be a good one for us to apply to Invoke nodes. Your original suggestion was to hide the terminals. In the subVI view, the terminals aren't hidden, but they default to a collapsed view, so they take up less vertical space. Would that be something you would find acceptable, or would you prefer them actually hidden? Note that the "final advantage" about opening in different versions of the API should (or at least could) still apply regardless of whether the terminals are fully expanded, stubbed out or fully hidden.

 

My appologies... I didn't remember that the gray meant "optional". Since all the terminals were gray, it didn't register that they were special.

dafemec
Member

My apologies, Aristos, for not getting your point about View As Icon; now I see what you are suggesting, and I appreciate your taking the time to explain it.  I think I would prefer a look in keeping with the current style of Invoke nodes, but let the developer select just the optional arguments needed.

AristosQueue (NI)
NI Employee (retired)

Acknowledged. Thanks for the clarification.

David_L
Active Participant

I think this is a great idea, but the key would be something like Jack proposed.  We would need to offer some sort of visual clue that there are other inputs that are available.  Otherwise there would be people who would be confused as to where these other options are.  

dafemec
Member

Jack's proposal is fine, David, but, as with Property nodes, just resizing the Invoke node should also work.  My principal concerns are real estate -- I would like to not have to have all of the optional arguments exposed -- and not having to re-select the method in the Invoke node just because the version of, for instance, Word is different on another development PC.  I realize that I will have to "touch" the code if I have exposed optional arguments that are not available in that different version of Word, but I think how often this needs to happen can be reduced.  I also have to keep in mind that these suggestions are just suggestions -- NI is no way bound to do what any of us are suggesting, nor in the way we are suggesting.

PJM_Labview
Active Participant

kudo (using Jack "Chevron" symbol)



  


vipm.io | jki.net