Real Time Menu Ref Wire Not Supported

[Hooovahh]

Okay so I have some scripting that generates actor like code with several templates to work from.  They are all generally a single loop state machine with some code to handle common operations, and common UI operations.  I wanted to take one of these actors and put it on an RT target but I get a compile error because I have a Menu Reference, and that isn't supported.  

I understand I can't use a menu ref on RT because it doesn't have a UI to work with, but I'd still like to have this be part of the template code so I can use it when it is on RT.  I tried using a conditional disable structure so my code doesn't use the menu ref when on RT, but I still get an error because the wire is there.  I can't seem to find a good solution.  I can ask the user when generating the code if the actor is intended to work on RT, and then delete that case if it is, but that sucks cause you might not know if you want the code to work on RT in the future.  The other option is I could wrap the whole event structure in a conditional disable, and then in the RT case have the Menu event deleted.  I think the compiler should be smart enough to know that while this data type exists on RT it isn't being used on the RT target and should allow the compile.

[thuyanhl]

Hi,

I think your second option sounds the best. If that does not work, you might have to create a new template for your RT target. 

Let me know how it goes!

Best Regards,

[drjdpowell]

---

@Hooovahh wrote:

I think the compiler should be smart enough to know that while this data type exists on RT it isn't being used on the RT target and should allow the compile.

---

I've been using similar templates on RT recently and I had exactly the same problems.  Menu operations should just be no-ops on RT rather than failing to compile.  

[CoastalMaineBird]

Maybe you could try casting the MenuRef to a U32 and carry around the U32 with your actors.

When it's time to act, cast it into a MenuRef if you're on the host target.

[drjdpowell]

---

@CoastalMaineBird wrote:

Maybe you could try casting the MenuRef to a U32 and carry around the U32 with your actors.

When it's time to act, cast it into a MenuRef if you're on the host target.

---

Doesn't work because of the Event Structure, which has a MenuRef as part of the Menu events.  

[Hooovahh]

---

@CoastalMaineBird wrote:

Maybe you could try casting the MenuRef to a U32 and carry around the U32 with your actors.

---

Right as mentioned the fact that the wire exists on the block diagram, and is wired to a cast function would break the VI.

I made an idea on the idea exchange, but the RT idea exchange seems stagnant.  For now I'm just going to manipulate my templates to not use menu references, I really was only using them in one place for something that could be done with buttons, but thought it was slicker with menus

[paul_cardinale]

The 'Menu Ref' output is a named unbundler (just like for a cluster).  It is owned by the frame that it's in.  You can get a reference to it, then in the RT case, change it to refer to something other than the 'Menu Ref' (e.g. 'Source').

[Hooovahh]

Paul I don't think it works that way (unless I miss understand you).  Remember I want a single template, that can be used on RT and Windows.  I can have scripting code that changes from one to the other, but I want the templates to not need changing to work on one or the other.

Attached is a zip with a project with a Windows target, and a RT target.  On Windows I want a runtime menu option, but on RT I want to ignore the menu (since it doesn't work) but the VI is broken because the Menu Reference wire exists on the block diagram.  You are right that the terminal is like an unbundle by name, but I'm unaware of a way to get a reference to that terminal.

[paul_cardinale]

Here's one way to do it:

[PiDi]

---

@Hooovahh wrote:

(...) You are right that the terminal is like an unbundle by name, but I'm unaware of a way to get a reference to that terminal.

---

Traverse for GObjects.vi to the rescue - see the attachment.

EDIT: Yeah, it's the same as paul's above ;D