07-22-2025 10:36 AM
This is my first application using the actor framework and I have come across some issues, the project is only really for me to lean and understand the framework but i thought it an interesting task.
The intention of this application is to create a dynamic alterable user interface for graphs and digital displays so that at run time a display can be chosen from a dropdown and allocated a subpanel. Additional subpanels can be added as an actor with two subpanels separated by a movable splitter, a display could then be added into each of those panels or another actor with 2 subpanels. Using this arrangement I was hoping to allow an operator to lay out a page including the displays they require and assigning channels to the displays on the page.
The Launcher.vi launches a master actor that embeds its self in to the subpanel on the front panel.
Master.lvclass:Actor Core.vi contains a subpanel on its front panel and a button. my intention was to right click the front panel and select what actor to embed in this subpanel however the right click on an embedded subpanel does not work [Issue 1.] Is this a known problem or am I doing something wrong?
I have added the button to allow the shortcut menu to appear and this does work (Master.lvclass:Shortcut menu.vi). The choice of ‘digital’ should send the selection to Master.lvclass:Select sub panel.vi and launch 'Digital Indicator' Actor and allow it to embed its self in the 'master' actors subpanel.
The issue I have is that Master.lvclass:Select sub panel.vi seems to always launch a 'master' actor and embed this in the subpanel. I do not understand why. [Issue 2.]
The Get LVClass Name.vi and dialogue box shows that the correct Class (digital indicator) is being sent into the launch actor but the master class actor is launched. as can be seen in the above image. I would expect instead of a second button visible a digital display would be embedded (from Digital Indicator.lvlib:Actor Core).
I am sorry this is a not a small VI to look at but as my aim is to learn Actor framework I don’t think I could simplify this. Any assistance would be greatly appreciated and any other advice would be greatly received. I have saved to previous from 24.3f3 to 21.0 (i hope the version does not make a difference).
Solved! Go to Solution.
07-22-2025 03:05 PM
07-22-2025 03:15 PM
Thank you for your reply.
AHH yes there is! I was trying to ensure whatever actor was called would include all necessary methods that could be sent to it.
What is the logic as to why it calls the parent? Should actors as a rule not inherit from other actors to avoid this?
I could use an interface for all panel inserts it's this the logical solution?
07-22-2025 04:16 PM - edited 07-22-2025 04:19 PM
In Actor Core the "Call Parent Class Method" must always be invoked so if your actor inherits from another actor with an Actor Core override, that will show up when doing something like what you're trying.
In general, if you have common UI functionality that you want multiple actors to inherit, I'd consider making a generic UI actor (that doesn't show its Actor Core override, if it exists) that other UI actors inherit from. So in your case both Master and Digital Indicator would both inherit from UI Actor, but not Digital Indicator from Master. Hopefully that makes sense.
As far as interfaces vs a base actor, if possible, I think the idea to put the UI functionality in an interface vs a class is a good one.
07-22-2025 04:35 PM
Use inheritance to implement "is a" relationships. Your case represents the relationship "Digital Indicator" is a "Master" which doesn't sound right.
"Digital Indicator" is a "Generic Display" sounds better.
Also, I'd recommend using MGI's Panel Actor framework, and inheriting all of your display actors from their Panel Actor class. It's a very handy toolkit.
07-23-2025 03:15 AM
CaseyM, Thank you i reread your response and i understand now and can see it in the code, The 'Call parent Method' calls the master actor core and inserts its own VI ref into the object data to embed into the sub panel. It's clear when some one tells you :). I was trying to be clever and reuse the code from the parent, can it won't be that easy.
BertMcMahan, that makes sense and its clear my naming convention and hierarchy needs changing, once you put your head down you forget the basics. I will have a look at MGI's i was sure that someone had done this before but wanted to try it out.