Different Actor Core With Different GUI Interface On Child Class

[Jimmy01]

So I have class containing an actor core which is the main GUI for my application. This is quite a busy interface and so I would like to now make a child class of this with a completely different GUI which would be suitable for a different type of user such as a technician. However if I want my child class to overwrite the parent actor core then I must call the parent on the block diagram of my new actor core but this makes no sense for what I am trying to achieve because I don’t want all the extra event structures and references that are present in my parent to spin up when I launch the child actor core. I essentially want a fresh actor to start just as the parent does when it starts.

Also this vi has multiple panes so adding tabs for the new interfaces is out of the question on this one.

Any help is greatly appreciated.

Thanks

[D_Hooks]

Try creating an Abstract GUI Actor that implements whatever central functionality that is common to both of the GUIs you are trying to develop.  This actor does not need to have an Actor Core override with an event structiure.

Then create two separate child actors, lets call them Basic GUI Actor and Advanced GUI Actor.  Each of these will include an Actor Core override that contains an event structure and the call parent method. 

From your application's Main Actor (which should be separate from the Abstract GUI Actor, if it is not already), you can choose with of the child GUI classes to launch and interact with.

Hope that helps!

[wrkcrw00]

Use Loose Coupling.

Create an Actor "GUI Core". The GUI Core actor handles the messaging to and from other actors that do whatever business or logic you have going on (I'm assuming your GUI actor is only a GUI).

For receiving UI updates, create DD methods for handling each of the different updates you recieve. Create a child of the GUI Core that has an Actor Core override with all the actual controls and indicators. This child simply overrides the parent methods and update the GUI appropriately.

To send commands or data from the GUI to the processes that do the business, create a method (and message) in GUI Core that calls the appropriate message to the outside world. The child class then calls the GUI Core message, which in turns calls the external message.

It's a little extra work, but now, if you want to create different GUI's, it's quite easy. The GUI Core (which has no actor core.vi btw) is made such that it can handle any possible incoming or outgoing message traffic. It's the child overrides that have the controls and indicators.

As such, you could have 1, 2 or 50 different children, each with their own assortment of GUI elements, but all using the same GUI Core. Now you have a customizable GUI based on whoever needs to use it (i.e. an operator might only need access to the most basic controls and data, whereas an engineer might need to see all the low level controls and data).

[Brainstorms · Accepted solution]

Let's see if I understand what you're trying to do...

You have an actor that implements a complicated GUI...

You want to subclass this actor's class to make another actor class, with a simpler GUI...

You want the Actor Core override in the simpler GUI actor to enter its Actor Core loop without also calling its parent method, which would start the complicated GUI...

Correct so far?

If this is the case, then let's assume that the inheritance parent of the complicated GUI actor is "Actor.lvclass".  (It could be something else, such as "State Pattern Actor.lvclass", etc., but let's assume its superclass is Actor.lvclass.)

Then what you do is, just upstream on the actor object wire going into your Actor Core CPM VI, insert a "To more generic class" VI and use an instance object of the parent of the complicated GUI actor to wire to the center terminal.  This re-types the actor wire as the parent of the complicated GUI actor.

Then replace the CPM VI call with the Actor Core.vi of the superclass of your complicated GUI actor.  This will cause the call to bypass the complicated GUI actor's Actor Core.vi override, and still run Actor Core for your simpler GUI actor.

[Brainstorms]

I think the above 3 responses all show the same core point:

Don't link a GUI with an actor with any significant functionality beyond servicing the GUI itself.  GUIs should stand alone as an independent entity, and the actors that actually "do the work" should remain "headless" and I/O the data & events pertaining to GUIs -- and other interfaces.

In other words, de-couple the GUI (human interface) from the data processing responsibility.

It's much more flexible this way, too: You can swap out the original GUI to a different one (with more or fewer features), or to a logger or network interface, etc.

[Jimmy01]

Ah Yes, this looks like it would be the simplest option to implement.

Thanks

[Brainstorms]

One should note that in the general case of using this technique (up-casting to invoke a higher ancestor's override instead of your immediate parent class's override), once the desired override has executed, you will most often want to use "Preserve Run-Time Class" to down-cast back to the original class on the wire.  The center terminal of this VI is wired back to connect to the wire going into the "To More Generic Class" node.

In this way, the object on the wire "has a temporary excursion as a grandfather class" in order to run a grandparent override, then returns to the same class it started out as.

[Jimmy01]

Ok, Im not sure I understand.

Why would I need to "Preserve Run-Time Class" In this situation becasue what i want to do is bypass the parent actor and spin up the actor core from the actor framework when I launch my actor. I would want it to run like this for the duration of the application session.

Is the ''Preserve Run-Time Class'' needed if i wanted for some reason to spin up up the parent actor core of the actual non bypassed class?

[fabric]

Brainstorms: There is no need to cast to the parent class in order to run a parent's method. The child, by definition, can execute all of the parent's (non-private) methods as well as its own methods. That is how inheritance works.

Using "To More Generic Class" does not actually work as you describe. Let's say we have a parent class X and a child class Y, and both have a dynamic dispatch method M. Casting Y to X and running M will STILL execute Y:M! The cast is really just cosmetic; the wire's actual type is retained even though the colour of the wire may have changed. To run the parent method X:M you need to use the "Call Parent Method" primitive.

[Brainstorms]

fabric, you are correct.  What Jimmy01 wants to do is run the grandparent's method, bypassing the parent's method (which the CPM would invoke).

What he has is class X with child class Y, with Y having child class Z.  Method A in class X has an override in both Y and Z.

What he wants is to invoke method A's override in class Z, then "Call Grandparent Method" in X, bypassing the override in Y.

The technique I outlined above will accomplish that.