Is it possible to add a single Entry Point menu item to a LabVIEW OI menu?

[Norbert_B]

Jeff,

i have good and bad news for you.

Good news is: i am very confident that you can do what you are looking for.

Bad news: You have to implement this on your own.

I started from Full-Featured UI and dug down how it works there. My findings:

1. Only the top-level items (e.g. 'EXECUTE') are defined in a custom runtime menu for the toplevel VI.

2. Once the user activates the menu during runtime, it triggers the "Menu Activation?" event in the toplevel VI. This essentially discards the old menu first (except the top-level items) and recreates the contents after that.

3. Recreation for 'EXECUTE' is done using the standard "Insert Commands in Menu" VI. This does NOT support what you are looking for. This is because this VI is created for using the "CommandKind_Defaultxxxx" commands.

4. You have to implement a VI similar to "Insert Commands in Menu" which enables you to pick specific Execution Entry Points instead of "everything".

The key point is that you have to go with "CommandKind_RunEntryPoint" which, stated in the help, is not recommended to include in direct calls for the menu. The Insert Commands in Menu VI does not honor the specifics for this command leaving a blank entry (hence: unselectable) when used with this VI with _RunEntryPoint. You have to adopt a specific VI for EXECUTE menu items.

I'm going to implement an example for internal training purposes. If i succeed, i will post some screens.

Norbert

[Norbert_B]

Jeff,

after fiddling around some time, i have to admit that it isn't that easy as expected. Nevertheless, during that time i already came up with some "workarounds":

1. Create a LV menu item (no TS one!) and handle its menu selection in the LV event structure. If the item is selected, fire a "DoClick" on the execution entry point button you "connect" to this. I hope you still have those nice TS entry point buttons on the UI, haven't you?

2. In fact, all TS execution entry point interactions from the UI are depending on the process model. So if you change the process model, the UI will automatically adopt to this. If your approach would work as you intent to, you would kind of bind the UI to a specific setup of a process model. From that point of view, changing the process model instead of the UI (as already recommended) makes equal sense.

There are additional, quite shady approaches which could also work out, but these two really are what i recommend to you.

Norbert

[Norbert_B]

Jeff,

there is also a third option:

Use the CommandKind_ExecutionEntryPoints_Set as in the original code, but then add code to remove the unwanted execution entry point item from the menu.

Or: Create a custom insert VI modifying the TestStand - Insert Command Collection in Menu.vi to only add the desired entry point to the menu at all.

Norbert

[jsiegel]

Norbert,

Thanks for the suggestions.  For what it's worth, in my attempt to recreate the "Insert Commands in Menu.vi" (as shown in my previous post), I used the "CommandKind_ConfigurationEntryPoints_Set" option (which seems to be okay to use, according to the help) instead of "CommandKind_RunEntryPoint" as you suggest.  But I think it still has the same problems.

I actually implemented your third suggestion of deleting specific menu items after adding the collection.  This seems better than creating my own LV menu item, because that requires me to add the logic for determining whether or not the menu should be enabled.  It does sort of tie me to a particular process model, but the first few Execution and Configuration Entry Points are pretty standard for different models.  And the Tools menu is tied to a station and not to the model.  I still have the problem with the Tools menu leaving unreleased objects, but perhaps that's a topic for another thread.