Inheritance or composition for UI actors?

[PsyenceFact]

I am creating a set of generic UI actors which encapsulate single controls (list box, table, tree, etc.) with the intention of using them in subpanels.  Each of these is the child of an abstract "UI Panel" actor which implements functionality such as show, hide, insert/remove in subpanel.  UI Panel requires an Actor Core override.

Each child handles events such as Pane resize in its Actor Core helper loop.  Messages are defined to send data to the control for display and perform various formatting tasks.  There is also a run-time menu on the control for common tasks such as copy data, write to text file, and so on.

What I now want to do is define a *something* which makes use of these UI actors in a more specific situation.  As an example, I want to use the list box actor to display data from a file with controls to select a file and define the data range to display.  I will then insert this *something* in a subpanel on the main application UI.

My intial attempt has been to make *something* an actor with its own Actor Core that displays the list box UI actor in a subpanel.  The enqueuer of the list box UI actor is stored in the private data of this new actor.  Using this method, I can't see a way to extend or alter the behaviour of the list box run-time menu (or intercept its operation at all).

I'm now considering making *something* a child of the list box UI actor instead.  I think I would have to override Actor Core, ending up with some duplicated code that would not keep track of any changes made to the parent actor.  I also remember reading somewhere about not making a concrete class the child of a concrete class, which is giving me doubts about the wisdom of this approach.

Would anyone care to chip in with observations on the approach, or how they may have managed similar situations of inheritance vs composition?

PsyenceFact

[BertMcMahan · Accepted solution]

It sounds like you're making an Actor version of a QControl. Have you taken a look at that toolkit? I have to say it's quite good. The MGI Panel Actor is also incredibly useful for managing panels/subpanels/etc.

It might be simpler to make an actor that has a QControl in it. It may save you some time.

Also, beware: if you're making your own popup menus (as in, a VI that launches and looks like a menu, not the normal right click menu), there is currently no way for a VI inside a subpanel to get screen coordinates of an item. You have to pass the main panel reference down to the subVI. Shameless plug for my IdeaExchange idea on this. 

Regarding your actual question though, I'm not sure why you can't alter the runtime menu. Can't your "something" actor configure your "control" actor internally? Maybe send it some configuration data as it launches. Let it still handle the right-click menu events. It would have some menu events it can handle that it knows how to do (for example, autosize a column or something), and it could have "upstream" menu items that it forwards to its caller if it doesn't know what to do with it. Just send the info as an abstract message back to your "something" launcher to actually "do stuff". Maybe I'm not quite understanding you.

[PsyenceFact]

Thanks for the reply, Bert.

Part of the point of this exercise is to improve my LV skills and help better understand LVOOP and actors in a practical setting, so reinventing the wheel isn't an issue.  I have some enforced time on my hands right now.

I'm using the standard run-time menu mechanism and determining what needs to be done based on item tags in the Shortcut Menu Selection (User) event.  I think you may have hit the nail on the head with regards to customisation and upstream processing.  I already have a decoupled message system in place so it should be straightforward.

PsyenceFact