"Menu Activation?" event returns illegal menu reference

[avogadro5]

When changing the runtime menu path programmatically via "Run Time Menu Path" VI server property, and registering for "Menu Activation?," the "Menu Activation?" event returns an invalid MenuRef.

However, if the VI that is having its menu bar managed has the "Current VI's Menubar" node on its block diagram, the event returns valid MenuRefs.

In my application I want to allow VIs to "register" to have their menu bar managed, which replaces the menu bar on the registrant with a shared .rtm and dynamically creates menu items on the "Menu Activation?" event. I created and attached a minimal version of what I'm trying to do (LV 2015):

On the first run of "main.vi," the "Menu Activation?" event returns "not a refnum" after the menu bar has been replaced, but on subsequent runs the references are valid presumably because the menu bar has persisted since the previous run. This behavior can be fixed by having "Current VI's Menubar" on the registrant's block diagram, even though the reference doesn't go anywhere:

Why is the menu reference node required?

[paul_cardinale · Accepted solution]

Seems like an LV bug.  At least you have a workaround.

[JÞB]

Just a guess ( but I am historically awesome at guesses)

Without any node that requires the FP to be in memory the Menu bar isn't in memory and no valid ref to the menu can be found to "Point" to the location in memory where it doesn't reside because...It's not IN memory

Of course, the ThisVIs RTM node HAS TO load the FP into memory so it can generate a "pointer" to the memory location the RTM is loaded in.

I'd say any node that requires the FP to be in memory would do the same thing as long as the menu is also shown.

Probably not a bug.   Now stop laughing!

[avogadro5]

I do also have a "FP.Open" prior to registering with the menu handler, but I still get illegal menu references unless I also drop the menu reference on the BD. Doesn't that force the FP to be in memory (I can't imagine anything more likely to do so)? Not to mention this happens with all the VI FPs open prior to run, with nothing reentrant.

I'll also point out that not setting the RTM path dynamically also results in valid menurefs coming in through the event structure, regardless of the menuref node existing on the registrant BD:

So, I think something is not playing nice between the node swapping out the whole menu bar at runtime, and later looking at the activation events.

Another thing I just tried is interacting with the default menu on the registrant before registering with my handler, on a crude hypothesis this would load something related, but I still get the illegal menurefs.

[JÞB]

---

@avogadro5 wrote:

I do also have a "FP.Open" prior to registering with the menu handler, but I still get illegal menu references unless I also drop the menu reference on the BD. Doesn't that force the FP to be in memory (I can't imagine anything more likely to do so)? Not to mention this happens with all the VI FPs open prior to run, with nothing reentrant.

I'll also point out that not setting the RTM path dynamically also results in valid menurefs coming in through the event structure, regardless of the menuref node existing on the registrant BD:

So, I think something is not playing nice between the node swapping out the whole menu bar at runtime, and later looking at the activation events.

Another thing I just tried is interacting with the default menu on the registrant before registering with my handler, on a crude hypothesis this would load something related, but I still get the illegal menurefs.

---

---

@avogadro5 wrote:

I do also have a "FP.Open" prior to registering with the menu handler, but I still get illegal menu references unless I also drop the menu reference on the BD. Doesn't that force the FP to be in memory (I can't imagine anything more likely to do so)? Not to mention this happens with all the VI FPs open prior to run, with nothing reentrant.

I'll also point out that not setting the RTM path dynamically also results in valid menurefs coming in through the event structure, regardless of the menuref node existing on the registrant BD:

So, I think something is not playing nice between the node swapping out the whole menu bar at runtime, and later looking at the activation events.

Another thing I just tried is interacting with the default menu on the registrant before registering with my handler, on a crude hypothesis this would load something related, but I still get the illegal menurefs.

---

FP open Method is dynamic.. it doesn't load the FP until it runs (and not always then).  The get RTM requires the FP to be in memory when the vi object loads even in an idle state 

You are doing well managing to confuse yourself this week.  

[avogadro5]

---

You are doing well managing to confuse yourself this week.  

---

I suppose so, since I still don't quite get how I can be looking at and clicking buttons on the FP if it's not in memory. I am registering for the Menu Activated? event after opening the FP, in some tests I ran long after. Again nothing funny like reentrancy, multiple app instances, what have you.

[paul_cardinale]

---

@JÞB wrote:

---

@avogadro5 wrote:

I do also have a "FP.Open" prior to registering with the menu handler, but I still get illegal menu references unless I also drop the menu reference on the BD. Doesn't that force the FP to be in memory (I can't imagine anything more likely to do so)? Not to mention this happens with all the VI FPs open prior to run, with nothing reentrant.

I'll also point out that not setting the RTM path dynamically also results in valid menurefs coming in through the event structure, regardless of the menuref node existing on the registrant BD:

So, I think something is not playing nice between the node swapping out the whole menu bar at runtime, and later looking at the activation events.

Another thing I just tried is interacting with the default menu on the registrant before registering with my handler, on a crude hypothesis this would load something related, but I still get the illegal menurefs.

---

---

@avogadro5 wrote:

I do also have a "FP.Open" prior to registering with the menu handler, but I still get illegal menu references unless I also drop the menu reference on the BD. Doesn't that force the FP to be in memory (I can't imagine anything more likely to do so)? Not to mention this happens with all the VI FPs open prior to run, with nothing reentrant.

I'll also point out that not setting the RTM path dynamically also results in valid menurefs coming in through the event structure, regardless of the menuref node existing on the registrant BD:

So, I think something is not playing nice between the node swapping out the whole menu bar at runtime, and later looking at the activation events.

Another thing I just tried is interacting with the default menu on the registrant before registering with my handler, on a crude hypothesis this would load something related, but I still get the illegal menurefs.

---

FP open Method is dynamic.. it doesn't load the FP until it runs (and not always then).  The get RTM requires the FP to be in memory when the vi object loads even in an idle state 

You are doing well managing to confuse yourself this week.  

---

Still wrong.  Forcing the FP to be in memory before the code runs still doesn't fix the problem.

[paul_cardinale · Accepted solution]

Here's an alternative workaround (but it's ku-razy, and may be hazardous).

[avogadro5]

Ha well that works, and then we have the opposite problem of erroring on the 2nd and later runs.

Fortunately all my callers happen to already have the menu reference node since it used to be required, but now it just hits the registration VI and goes nowhere...