Invoke Menu Item Scripting

[Hooovahh]

There has been a private function sitting dormant for several years in LabVIEW that has been teasing me.  There are times when I've wanted a way to programatically invoke a run-time menu item.  Some times this is for automation and I just want a single button to perform a set of steps in code that is already developed.

The current private method that doesn't appear to work is called Invoke Built in Menu Item, and there is also another one that could be useful, the Get Menu Item Status, which returns if a menu item is enabled or not.  Here's an example.

Here is a custom menu item that was made to perform some operations.

And here is the code where when the user chooses to Load a Config that we handle their selection.

This idea is to complete these two private not implemented functions, so that menu item status can be queried, and invoked so that code reuse can take place, and automation of already created applications.

The work around today either involves programatic mouse clicking, or keyboard invoking to open menu items and navigate to them which is usually platform dependent, and error prone.

[AristosQueue (NI)]

This idea is something I would push back on hard.It violates the separation of implementation and interface in a way that observation shows typically leads to hard-to-maintain software.

Customize the runtime menu of a VI, then start it running. Now try to go to its block diagram by hitting ctrl+E... becuase there's no menu item for that, it doesn't do anything. That's a very frustrating thing, and it happens because the commands for the running VI and the commands for the debugging shell are both the same menu.

Your suggestion would make this situation worse by making it a part of the end user code. The UI presentation of options for the user should not affect whether or not the code can execute that statement. In other words, you should not call a menthod "Do menu item File >> Save"... instead you should call a method "Save" and go direct to the functionality, without triggering the UI at all.

> The work around today either involves programatic mouse clicking, or keyboard

> invoking to open menu items and navigate to them which is usually platform dependent, and error prone.

The workaround today should be to test whatever properties the menus are testing and then calling the functions those menus are invoking. If there's a specific operation whose properties you cannot test or functionality you cannot invoke because it isn't exposed somewhere, make a request that we add that functionality. The general solution requested here is a can of worms that I'm pretty sure is bad to open.

[AristosQueue (NI)]

For example, this idea takes the correct (IMO) approach:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-Invoke-Node-or-Property-Node-to-quot-Duplicate-Sca...

[Hooovahh]

You make the assumption that source code is available, and that changes to the code can be done.  There's quite a few NI made soft front panels that I think do 90% of what I want, but there are times when I'd like to automate configuring it a bit and doing things like changing control values through scripting is something I can do today, but invoking menu items is something I cannot do.

Of course I think you would argue that invoking control value changes using something like Value Signal, has caused more issues than it has solved over the years.

Also if we talk about this being a function of both run time and edit time, then this could open up a few more features for the IDE.  Allowing any shortcut menu to be invoked would be a step closer to this idea, shortcuts could be made for user made Tools menu items.

But I do see your point.  Out of curiosity do you have any comments on these two private methods other than "don't use them", like maybe why they were partially made in the first place, or their intended purpose internally?

[AristosQueue (NI)]

> Of course I think you would argue that invoking control value changes using

> something like Value Signal, has caused more issues than it has solved over the years.

No, but it is a close balance. 🙂 There are plenty of ways to use Value (Signaling) in a good way, and I think those outnumber the abuses. But, yeah, it has been a source of pitfalls.

> But I do see your point.  Out of curiosity do you have any comments on these two private

> methods other than "don't use them", like maybe why they were partially made in the first

> place, or their intended purpose internally?

Looks like a temporary hack to make a prototype that never went anywhere. But I'm not sure.

[AristosQueue (NI)]

PS: I'm not suggesting we close this idea... I don't like it, but maybe there's others who think it's a good idea, and enough support might push it forward.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.