Set Menu Item Info - How to make the Shortcut menu input a no-op?

[bjustice]

Ok, I found something.  And it really feels like this disobeys the Laws of LabVIEW physics.

 

It would be my expectation as a LabVIEW developer that both the top and bottom code should execute exactly the same.  (The constant short-cut cluster wired into the "Set Menu Item Info" function is the default value of the cluster, created by right-click + create constant from the terminal of the VI.)  I would expect the default/blank value to yield a no-op.

However, if you run the attached VI, you will find that the top screenshot produces an error.  The bottom does not.

button right click menus are not allowed to have shortcuts.  And that's fine.  But I can't figure out how to wire a cluster to this NI primitive in a way that let's me communicate a desired no-op behavior.

I'm scratching my head trying to determine how this even works.  Does this mean that the NI primitive is able to have code that discerns and reacts to whether or not an input terminal is wired?  It seems like that breaks LabVIEW paradigm.

Ok, that's all.  Saw something weird and wanted to share.

Menu example.vi

[ShaunR]

Only main menu's can have keyboard shortcuts and yes. LabVIEW can tell if something is wired to a connector. It's how polymorphism works and why you get a broken run arrow for required terminals if you don't connect them.

Edited November 20, 2022 by ShaunR

[Neil Pate]

22 hours ago, ShaunR said:

Only main menu's can have keyboard shortcuts and yes. LabVIEW can tell if something is wired to a connector. It's how polymorphism works and why you get a broken run arrow for required terminals if you don't connect them.

I dunno, something about this feels fishy to me. I agree with @bjustice this feels like a bug (or perhaps just a badly designed API).

This is not the same as polymorphism as the connector pane is not changing. We could not write any normal LabVIEW code that had this same behaviour.

Edited November 21, 2022 by Neil Pate

[Rolf Kalbermatter]

3 hours ago, Neil Pate said:

This is not the same as polymorphism as the connector pane is not changing. We could not write any normal LabVIEW code that had this same behaviour.

No we can't and neither can NI for VIs. But these nodes are built in and the C code behind those nodes can exactly do that and regularly does. Same about custom pop-up menus for nodes. You can't do that for VIs.

Pretty much all light yellow nodes (maybe with an exception here or there where a VI fakes to be a node) are built in. There is absolutely no front panel or diagram for these, not even hidden. They directly are implemented as LabVIEW internal objects with a huge C++ dispatch table for pup-up menus, loading, execution, undoing, drawing, etc. etc. The code behind them is directly C/C++. It used to be all pure C code in LabVIEW prior to about 8.0, with hand crafted assembly dispatcher but most probably got eventually all fully objectified. Managing 100ds of objects with dispatch tables that contain up to over 100 methods each by an Excel spreadsheet, with command line tools to generate the interface template code is not something that anyone wants to do out of his or her free will. But it was in the beginnings of LabVIEW the only way to get it working. Experiments to use C++ code at that point made the executable explode to a manifold of the size when using the standard C compiler and make it run considerably slower. The fact it is all compiled as C++ nowadays likely still is responsible for some of the over 50 MB, the current LabVIEW executable weights, but who cares about disk space nowadays as long as the execution speed is not worse than before.

Edited November 21, 2022 by Rolf Kalbermatter

[Neil Pate]

1 hour ago, Rolf Kalbermatter said:

No we can't and neither can NI for VIs. But these nodes are built in and the C code behind those nodes can exactly do that and regularly does. Same about custom pop-up menus for nodes. You can't do that for VIs.

Pretty much all light yellow nodes (maybe with an exception here or there where a VI fakes to be a node) are built in. There is absolutely no front panel or diagram for these, not even hidden. They directly are implemented as LabVIEW internal objects with a huge C++ dispatch table for pup-up menus, loading, execution, undoing, drawing, etc. etc. The code behind them is directly C/C++. It used to be all pure C code in LabVIEW prior to about 8.0, with hand crafted assembly dispatcher but most probably got eventually all fully objectified. Managing 100ds of objects with dispatch tables that contain up to over 100 methods each by an Excel spreadsheet, with command line tools to generate the interface template code is not something that anyone wants to do out of his or her free will. But it was in the beginnings of LabVIEW the only way to get it working. Experiments to use C++ code at that point made the executable explode to a manifold of the size when using the standard C compiler and make it run considerably slower. The fact it is all compiled as C++ nowadays likely still is responsible for some of the over 50 MB, the current LabVIEW executable weights, but who cares about disk space nowadays as long as the execution speed is not worse than before.

Rolf, what I meant was that the bevaiour as manifested is strange and unexpected, and not even something we could recreate in our own code.

[ShaunR]

27 minutes ago, Neil Pate said:

Rolf, what I meant was that the bevaiour as manifested is strange and unexpected, and not even something we could recreate in our own code.

If you wire a keyboard shortcut cluster to a popup menu it gives you an error stating that it is the incorrect type. That's correct. You can only have keyboard shortcuts on main menu refnums. The alternative is to have separate primitives for main menu's and pop-up menu's-one with a shortcut terminal and one without.

We can recreate the same behaviour with xnodes where we can detect if anything is connected and it's type with abilities.

[Neil Pate]

9 minutes ago, ShaunR said:

If you wire a keyboard shortcut cluster to a popup menu it gives you an error stating that it is the incorrect type. That's correct. You can only have keyboard shortcuts on main menu refnums. The alternative is to have separate primitives for main menu's and pop-up menu's-one with a shortcut terminal and one without.

We can recreate the same behaviour with xnodes where we can detect if anything is connected and it's type with abilities.

The point is more about the difference in behaviour with connecting the cluster and not having it connected (even though the data in would appear to be the same(. I would expect most LabVIEW developers to assume the code would function identically in both circumstances, as detailed in the OP. I cannot think of any other nodes that work like that. That is confusing and inconsistent behaviour and should not be present. 

[ShaunR]

23 minutes ago, Neil Pate said:

The point is more about the difference in behaviour with connecting the cluster and not having it connected (even though the data in would appear to be the same(. I would expect most LabVIEW developers to assume the code would function identically in both circumstances, as detailed in the OP. I cannot think of any other nodes that work like that. That is confusing and inconsistent behaviour and should not be present. 

It cannot function identically since YOU CAN NOT HAVE SHORTCUTS ON POPUP MENU'S. You can argue that maybe it should morph to hide the connector but then you're just as likely to have people scratching their head when using menu's. With this behaviour you get an explicit error telling you " Run-time menu shortcuts are not supported for this type of menu.". 

Remember. This is a run-time check, not a design time check. You get the same behaviour if you try to operate a function on an invalid type after coercion to a more specific type.

Edited November 21, 2022 by ShaunR

[bjustice]

Yeah, Neil understands me here

A shortcut cannot be a blank string.  So, I would expect a blank string, which is also the default value of the input, to yield a no-op.

I created my own abstraction layer to sit on to of the low level menu API.  My abstraction layer is used by both by my main menu as well as by control references.  So, this behavior forced me to write a comical piece of code where I case structure 2 copies of this NI primitive, where 1 case does not wire up the shortcut input.

[ShaunR]

50 minutes ago, bjustice said:

A shortcut cannot be a blank string.

It can. This is how you clear a shortcut if one was set.

[bjustice]

24 minutes ago, ShaunR said:

It can. This is how you clear a shortcut if one was set.

ooooooooooh, ok, I didn't recognize this.

Now it makes more sense why NI chose to implement this the way they did.