Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

References from ActorCore.vi FP and Inheritance

Solved!
Go to solution

Hey guys,

 

I have the problem that the ActorCore references of BaseView overwrite the references of its child actor TestpanelView:

 

- In ActorCore.vi of the BaseView class I save e.g. the VI server reference or string refence into private class data (see attachment)

- In ActorCore.vi of the TestpanelView class I want to save the same (see again attachment), but when launching the actor, the BaseView class ActorCore.vi will be started which then overwrites the references saved from TestpanelView class

 

It seems to me that there is no fine way around calling the direct parent Actor core.vi...

 

Is there any way to get around this problem? What does best practice suggest in this case?

 

Background info:

I am trying to create an Actor-based Framework that uses some kind of MVC principle (Model - View - Controller). I use actors that act only as a view and are fed by a different actor via messages.

To make this possible the "View"-Actor has to save some references like VI reference or String Control References that are then manipulated in its own class methods, triggered by messages by an external controller class.

 

I would like to allow our developers to inherit from base views to simplify their programming. Most of the methods are then located in the base class and code can be reused.

To achieve that I want to supply a BaseView Actor that e.g. inherits to TestpanelView Actor that might again inherit to somebody.

 

 

Thanks in Advance!

 

Download All
0 Kudos
Message 1 of 14
(2,310 Views)

When I've done that type of inheritance before, I never write This VI in the BaseView, only in the inheriting actors. But you have a good point that it isn't extendable beyond one level of inheritance.

 

By the way, you might like using class property nodes for your framework, I find they make a much neater block diagram when passing in lots of Control References like you're describing.

0 Kudos
Message 2 of 14
(2,294 Views)

Hi Jenso,

If i understand well your problem, there is a way to solve it.

Use the snippet attached to create a sub VI for your BaseView actor to assign a private data for the reference.

Then call it just before the parent actor core of the BaseView 's actor core.

The ref will always be valid for any child of this class, whatever the child depth it has. Use a read only property in your child class to access it.

Get actor core ref.png

Message 3 of 14
(2,290 Views)
Solution
Accepted by Jenso

In the data accessor VI, you could check to see if the property already contains a valid reference. If so, skip setting the value. This would mean that the property will keep the value from the first VI to write to it. If you always write that property in your Actor Core overrides, then the first class to write to it should be the class at the bottom of your inheritance chain since the write will take place before the call parent VI. (This sounds like your desired behavior).

 

This method breaks down if you need to write to that property from different places in different child classes (it becomes much harder to guarantee the write order) or if you ever need to overwrite that value during the lifecycle of your actor.

 

I use a similar strategy in some of my applications, so I'm interested to hear any better ideas too.

Message 4 of 14
(2,287 Views)

Hey Jenso,

 

may be this is usefull for you. Look at https://github.com/keale/Viewable_Actor for more details.

 

 

0 Kudos
Message 5 of 14
(2,279 Views)

@OneOfTheDans wrote:

I never write This VI in the BaseView, only in the inheriting actors.


Exactly this. I too only wire This VI in the subclassed GUI actor.

 


@OneOfTheDans wrote:

But you have a good point that it isn't extendable beyond one level of inheritance.

Could you elaborate on this? I didn't quite understand.

 

If the OP's intent is to have both, BaseView VI reference and TestPanel VI reference both available to the subclassed actor, then the data member holding the base's reference should be different from the data member in the subclass (TestPanel), assuming both have a valid reason to exist concurrently in the OP's design. In that case, the BaseView's VI reference would be written to a different setter (say, SETUP BASE UI, from the OP's screenshots) in the BaseView actor core. The TestPanel will still use the SETUP UI to hold the sub-classed actor's VI reference. Since Call Parent Method is expected to be mandatory even in the sub-classed actor core, both references should now be available to the subclass.

0 Kudos
Message 6 of 14
(2,243 Views)

@Jenso wrote:

It seems to me that there is no fine way around calling the direct parent Actor core.vi...


Referring to my post above, you can choose to create a 'getter' VI to output the Base Actor core VI reference, and use it in your TestPanelView actor. Just curious, is your BaseView also a GUI? Why do you need its reference in TestPanelView?

 


@Jenso wrote:

To make this possible the "View"-Actor has to save some references like VI reference or String Control References that are then manipulated in its own class methods, triggered by messages by an external controller class.

 

I would like to allow our developers to inherit from base views to simplify their programming. Most of the methods are then located in the base class and code can be reused.

To achieve that I want to supply a BaseView Actor that e.g. inherits to TestpanelView Actor

I do exactly this. However, my case, the Base actor's core is NOT a GUI. In fact, I don't even override 'Actor Core.vi' for this base actor. The equivalent of 'SETUP UI' of your picture, I use to build a control/indicator reference dictionary. With that I have static dispatch methods created in the Base class that do a 'show', 'hide', 'enable', etc. of various front panel elements using the string labels. My various Panel subclasses, which are indeed GUIs, use the above methods as needed, and manipulate the state of their respective front panel elements based on the AF messages received.

 


@Jenso wrote:

What does best practice suggest in this case?

I want to supply a BaseView Actor that e.g. inherits to TestpanelView Actor that might again inherit to somebody.


I would discourage this. Multi-level class (not interface) inheritance has proven to be a headache for OOP practitioners across OOP-capable languages in the context of feature enhancements and code maintenance.

 

Composition is favored instead. In the case of GUIs, you could consider composing via subpanels.

0 Kudos
Message 7 of 14
(2,198 Views)

Ok, that one is really easy... That is a good workaround! Thanks a lot!

0 Kudos
Message 8 of 14
(2,029 Views)


Just curious, is your BaseView also a GUI? Why do you need its reference in TestPanelView?

That was originally not intended. But during development I was some kind of lazy and first developed the base class as a view to test the subpanel functionalities. When I then inherited to a child class I stumbled upon the problem and realized that this would have an impact to multi-level inheritance.

 

I would discourage this. Multi-level class (not interface) inheritance has proven to be a headache for OOP practitioners across OOP-capable languages in the context of feature enhancements and code maintenance.

 


Ok so that is bad to hear. I thought that I could now make a leap to lightspeed with developing an AF OOP Framework 😀. Can you give me one or two examples for these problems? I only remember this to be a problem in languages where you can inherit from multiple parents.

 

Composition is favored instead. In the case of GUIs, you could consider composing via subpanels.


 

How could an approach to composition then look like? I do not have a multi-parent inheritance (multiple inheritance is only allowed for interfaces as far as I know). So in my thinkings I would approach that by creating let's say libraries for specialized tasks.

In the example above when I have a testpanel view (e.g. one for each resolution) then I would use a testpanel library containing the most important methods and then use those in each view? 

0 Kudos
Message 9 of 14
(2,028 Views)

 


@OneOfTheDans wrote:

But you have a good point that it isn't extendable beyond one level of inheritance.

Could you elaborate on this? I didn't quite understand.

 

If the OP's intent is to have both, BaseView VI reference and TestPanel VI reference both available to the subclassed actor, then the data member holding the base's reference should be different from the data member in the subclass (TestPanel), assuming both have a valid reason to exist concurrently in the OP's design. In that case, the BaseView's VI reference would be written to a different setter (say, SETUP BASE UI, from the OP's screenshots) in the BaseView actor core. The TestPanel will still use the SETUP UI to hold the sub-classed actor's VI reference. Since Call Parent Method is expected to be mandatory even in the sub-classed actor core, both references should now be available to the subclass.


In my understanding, if you do not use SETUPUI.vi in the base class but in LVL1ChildView then you will have the same problem in LVL2ChildView because it will inherit from LVL1ChildView. Because LVL1ChildView is then the "Baseclass" of LVL2ChildView, the parental call of ActorCore.vi of LVL2ChildView will then again trigger SETUPUI.vi.

Because of that you can only inherit to one level. At least that is the way my bad-mood-thinkings led me.

 

One of the main advantages I see in multiple inheritances would be to be able to e.g. allow multiple resolutions or designs while keeping the Messages and methods maintained in one place.

And I would also be able to have a lot of code reuseability, if e.g. all Views use a method to communicate with the ViewManager Actor.

0 Kudos
Message 10 of 14
(2,025 Views)