Custom Shortcut Menu Plug-ins on Running FP

[paul_a_cardinale]

When I create a custom pop-up menu plug-in, it doesn't work on a running front panel.

Is there a trick/workaround?

[tst]

I don't remember trying to do something like this, but the selection in the creation VI does say "Run time (diagram only)".

[JÞB]

---

@paul_a_cardinale wrote:

When I create a custom pop-up menu plug-in, it doesn't work on a running front panel.

Is there a trick/workaround?

---

Nope, AFAIK a RTM is only loaded with the VI.   I suspect that a hidden Method could be made to exist to Update Runtime Menu but would need actual support in the LabVIEW Runtime Engine.  

The best I think that you could get is to unload the VI, replace the RTM file then Dynamically reload.  And even that might not work unless the code called pursuant to menu activation contains a superset of all possible menu options. 

I can be wrong. 

[JÞB]

---

@JÞB wrote:

---

@paul_a_cardinale wrote:

When I create a custom pop-up menu plug-in, it doesn't work on a running front panel.

Is there a trick/workaround?

---

Nope, AFAIK a RTM is only loaded with the VI.   I suspect that a hidden Method could be made to exist to Update Runtime Menu but would need actual support in the LabVIEW Runtime Engine.  

The best I think that you could get is to unload the VI, replace the RTM file then Dynamically reload.  And even that might not work unless the code called pursuant to menu activation contains a superset of all possible menu options. 

I can be wrong. 

---

And, I stand corrected!

• labview\examples\Dialog and User Interface\Menu\Customizing the Menubar\Customizing the Menubar.vi

By avoiding the Event Structure you CAN obtain a current menu reference and dynamically add menu items (I assume the Delete is there too.)  Then use polling and Get Menu Selection function  

Of course that doesn't seem like it would make a slick plug in  but results may vary.

[tst]

Jay, Paul is referring to the shortcut menu plugins you create with LV, which at least according to LV can't be used on a running FP.

You do bring up a good point, though, which is that the right click on the pane or an object can be intercepted in the code and then you can use that to handle the menu and call the relevant code from the plugin. I don't know if this will have all the data needed for the plugin and whether Paul's specific plugin can even be meaningfully executed on a running VI, but it is at least a workaround for some cases.

That said, I suspect Paul's goal is to have some kind of generic plugin which he can invoke on any running VI of his choosing, so I'm guessing this will not help him.

Like I said, I haven't checked for a workaround. Off the top of my head, you could possibly have a daemon running in the background and monitoring for all mouse clicks and trying to figure out if the click was on a relevant window and extract the details from that, but I expect this will be complicated and flaky and I don't think there's any way to get the menu reference from outside the VI anyway.

You could try using something like the VI Activation event to get the relevant VI and register for the menu event, but I don't know if that will work.

[wiebe@CARYA]

The plugins can be placed in 2 locations (4 actually, in LV dir and in user dir)  (How to install plug-ins that you download - NI Community):

• <LabVIEW Data>\PopupMenus\edit time panel and diagram
• <LabVIEW Data>\PopupMenus\run time diagram

I'd assume if you don't add them to run time diagram folder, they won't show on the run time front panel either.

That doesn't mean that if you do place them there, they will show, but it might help.. 

[paul_a_cardinale]

---

@tst wrote:

Jay, Paul is referring to the shortcut menu plugins you create with LV, which at least according to LV can't be used on a running FP.

You do bring up a good point, though, which is that the right click on the pane or an object can be intercepted in the code and then you can use that to handle the menu and call the relevant code from the plugin.

---

I like that, but how can a running VI find where the plug-in is?  Just look everyplace where it might be?  Or is there a clean way to find it?

[JÞB]

---

@paul_a_cardinale wrote:

---

@tst wrote:

Jay, Paul is referring to the shortcut menu plugins you create with LV, which at least according to LV can't be used on a running FP.

You do bring up a good point, though, which is that the right click on the pane or an object can be intercepted in the code and then you can use that to handle the menu and call the relevant code from the plugin.

---

I like that, but how can a running VI find where the plug-in is?  Just look everyplace where it might be?  Or is there a clean way to find it?

---

Ahhh ha!  Those RTMs ☺  

Strange idea!  Try loading the FP (heck even the BD) of an idle vi into a subpanel.  

[paul_a_cardinale]

---

@JÞB wrote:

---

@paul_a_cardinale wrote:

---

@tst wrote:

Jay, Paul is referring to the shortcut menu plugins you create with LV, which at least according to LV can't be used on a running FP.

You do bring up a good point, though, which is that the right click on the pane or an object can be intercepted in the code and then you can use that to handle the menu and call the relevant code from the plugin.

---

I like that, but how can a running VI find where the plug-in is?  Just look everyplace where it might be?  Or is there a clean way to find it?

---

Ahhh ha!  Those RTMs ☺  

Strange idea!  Try loading the FP (heck even the BD) of an idle vi into a subpanel.  

---

I don't see how that helps.

[tst]

---

@paul_a_cardinale wrote:

---

...how can a running VI find where the plug-in is?  Just look everyplace where it might be?  Or is there a clean way to find it?

---

No idea, I haven't gave it any thought. Off the top of my head, I would say that you either need to recreate what LV does (which is presumably look in all the relevant places) or link directly to the specific plugin or a copy of it.

Since you haven't given any details about what your use case is, I don't think I have more to add beyond that. I assume that there is no way to get LV to handle this on its own, leaving it up to you, but there is a difference between calling specific plugins for specific VIs, specific plugins for any VI or any plugin for any VI and that would affect what a practical solution might look like.