LabVIEW
Real Time Menu Ref Wire Not Supported
How can I run that VI before the actual VI runs every time, and change it one way or another, based on what instance it currently is? It is likely that the same VI (which came from the same template) will run on a RT and non RT target at the same time, from within the same project.
And yes I'm aware of scripting, but it won't work in a built application. I must not be explaining my situation well enough. I run the VI on one target, and it has a menu, I run the same VI on another target and it doesn't but does compile. That's what I want, and I'm guessing it is why the conditional disable structure was created.
Yeah I mentioned that option in my first post, but I tend to write too much so I don't blame you for missing the comment.
@Hooovahh wrote: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.
And the downside to this is obviously that if I make a change to one of the cases shared by the RT and Windows, like Timeout, and any dynamic events, then I need to make sure I make the same change in the other targets case which is also not ideal.
Could you create a simple event handler (in a conditional disable) just for the menu event and have it forward the event to the main event handler as a user event? You can typecast the menu reference and then re-cast it once it's back inside a conditional disable in the main event handler?
It's quite a lot of work/effort - but I think should serve the purpose that you're looking for? (should compile for RT/Windows, still handle the events in the main loop etc.)
@paul_cardinale wrote:Will this work? Or does the MenuRef control on the FP of the callback break it?
Apparently callbacks in general can't exist on RT either so that wouldn't work
Yes, that is a working solution. At the moment I think I will choose to redesign my template to avoid using shortcut menus. I hope that this just highlights the difficulties seen when using templates, and whole data types are set to break a VI on targets, even when not being used.
@paul_cardinale wrote:For a moment I thought that a detached event node might be a solution (see attachment).
Oh that was a great idea, I'm a bit disappointed that doesn't work, I would have owed you a few beers if it had.
@Hooovahh wrote:Yeah I mentioned that option in my first post, but I tend to write too much so I don't blame you for missing the comment.
@Hooovahh wrote: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.
And the downside to this is obviously that if I make a change to one of the cases shared by the RT and Windows, like Timeout, and any dynamic events, then I need to make sure I make the same change in the other targets case which is also not ideal.
I didn't miss this comment, I think you misinterpreted my snippet 😉 I meant the same solution as Sam - move everything that works on Windows only to other loop, leave everything else in "shared" loop. However, I'd make this a bit simpler than Sam:
(The second conditional disable has TARGET_TYPE==RT condition and is empty, lower loop is obviously stopped using user event). Compared to Sams solution, it does not need any more "infrastructure" elements (additional user events, type casting, etc) - you just put Win-specific code into lower loop, and shared code in upper loop.
