Nested Actors

[KuGr]

Regarding structuring actor hierarchies...

Some of us did not attend the CLA Summit and are not CLAs. Will this information be shared to us mere mortals? A separate thread might be useful. I have my own structure that would be tough to change now. It solves most of my use cases as a general framework.  But I am open to here what those that should know really think.

Kurt

[Ken_Jones]

Thanks guys,

Your suggestions and comments have made me realize that maybe I should restructure my architecture to not use nested actors.  The complication may out weigh the advantages.  Thanks for your help.

Ken J

[Q7]

I'm with Kurt here, my structure uses the actor core as the GUI because that's the way most of the examples have it. Those actors are just UIs though and don't do anything but change control states and send messages to a mediator. DO I NEED TO MAKE THESE DIFFERENTLY? I do run into a lot of trouble with odd UI behaviors and many of my UI Actor Cores do call on child/sibling Actor Core UIs.

If this was known since the last CLA summit than it should be in documentation here. Can somebody please create a comprehensive document or thread detailing where all these UI and control reference bugs are originating? Maybe someone in the community can take that info and suggest a novel solution before it gets fixed in LV 2013! I've got deployed instruments running this framework now & these issues demand thorough support.

Thanks,

-Jeremy Bjorlie

[David_Staab]

Kurt Grice wrote:

Some of us did not attend the CLA Summit and are not CLAs. Will this information be shared to us mere mortals?

As the recordings and slides from the summit presentations are only available through a private group on Community, I get the impression that they will not. Probably considered a value-add for having a CLA certification...can't say I have a problem with that since I'm certified. Your local user group can probably disseminate the ideas if you have a CLA interested in presenting, though. What I can tell you is that we basically spent a day pontificating about the best way(s) to implement the MVC design pattern into LV with and without AF.

[Daklu]

Kurt Grice wrote:

Some of us did not attend the CLA Summit and are not CLAs.

Some of us should present at the local user group and wrangle a free exam coupon out of the NI sales rep. 

jbjorlie wrote:

I do run into a lot of trouble with odd UI behaviors and many of my UI Actor Cores do call on child/sibling Actor Core UIs.

If this was known since the last CLA summit than it should be in documentation here.

For what it's worth I don't remember there being much discussion during the summit about creating class hierarchies of custom actors--especially with respect to UI actors.  Of course David might have attended different break out sessions than I did.  There was discussion about how to organize the application's control and communication structure for actors, but that is different than inheritance hierarchy.

jbjorlie wrote:

my structure uses the actor core as the GUI because that's the way most of the examples have it.

I don't know how to ask this without sounding condescending, but this really is an honest question:  Is your application's UI similar enough to the example's UI that it makes sense to copy the way it is implemented?  Examples are just that... examples to illustrate an idea or implementation.  They often contain functional limitations and code shortcuts that don't matter for the purposes of showing the topic of interest, but are not appropriate for all applications.

[David_Staab]

I use Actor Core.vi as the displayed panel of my concrete UI objects, Daklu. I don't really see a problem with it, but maybe that's due to either short-sightedness or a lack of need for extensibility in the UIs I'm writing.

[Q7]

Not condescending, at least I don't care if it is. My UIs are not similar to any example UIs except for the fact that they handle user events and are Actor Core VIs. I didn't see any reason to do otherwise and it seemed like a waste to have an actor core with no other function than to call a UI. I guess I could have done it that way but nobody ever indicated, in examples or documentation, that I needed to do that. To me it makes sense to have a set of sibling UI Actor Cores which I can call dynamically using the launch actor method.

Truthfully, I have seen such a reduction in performance moving to LVOOP and message based framework that I've been looking for safe ways of removing layers of abstraction rather than adding them. Maybe that's due to inefficient programming or incorrect class hierarchies but that's a different subject. Suffice to say, with ~900 VIs and 30+ Actor classes, my application takes > 30sec. to load and begin responding on a 1GHz Intel Atom machine running XPe. I don't want to add to that with dyn. dispatch UIs buried in Actor classes.

AF presentations & free exam coupons would be welcomed here in Tulsa!

[Wart]

I would make the drive up to Tulsa from OKC for that! 🙂

[Daklu]

David Staab wrote:

I use Actor Core.vi as the displayed panel of my concrete UI objects, Daklu. I don't really see a problem with it, but maybe that's due to either short-sightedness or a lack of need for extensibility in the UIs I'm writing.

I haven't done much with the AF, but I expect using them in that way would be safe.

jbjorlie wrote:

My UIs are not similar to any example UIs except for the fact that they handle user events and are Actor Core VIs. I didn't see any reason to do otherwise and it seemed like a waste to have an actor core with no other function than to call a UI.

My question was triggered in part by this comment in your earlier post:

"many of my UI Actor Cores do call on child/sibling Actor Core UIs."

Again, I'm not super familiar with the AF but two things struck me as potentially problematic.  First, my primary concern is the comment implies you are creating children from UI actors.  I'm having a hard time imagining a scenario where that would be useful and not solved better using other techniques.  I don't have anything I can point to and say "this will be a problem," but it does raise all sorts of unanswered questions in my head. 

Second is the comment that some UI actors are directly calling other UI actors.  Whether or not this is a problem depends a lot on what your messaging connections look like and how thick your UI layer and UI actors are.  Unless the message-receiving UI window was obviously a "child view" of the message-sending UI window I prefer to implement an actor to coordinate activities between all the visible windows.  This "view manager" actor can be implemented as a separate actor object or it can be as simple as a mediator loop on the block diagram of your main UI window.  Providing a centralized location for all UI messages to flow through allows the view manager to make sure each UI window is behaving correctly according to the application's state.

You didn't specify what kind of "odd UI behavior" you are seeing but either of these two concerns could lead to all sorts of unwanted UI behavior.

jbjorlie wrote:

Truthfully, I have seen such a reduction in performance moving to LVOOP and message based framework that I've been looking for safe ways of removing layers of abstraction rather than adding them...  I don't want to add to that with dyn. dispatch UIs buried in Actor classes.

Is it just loading times that have suffered or is run-time performance degrading as well?

Dynamic dispatch calls incur a fixed-time overhead regardless of the class hierarchy depth.  I think it's on the order of a few microseconds, but I don't recall the exact number.

[Todd_Lesher]

DavidStaab wrote:

Kurt Grice wrote:

Some of us did not attend the CLA Summit and are not CLAs. Will this information be shared to us mere mortals?

As the recordings and slides from the summit presentations are only available through a private group on Community, I get the impression that they will not. Probably considered a value-add for having a CLA certification...can't say I have a problem with that since I'm certified.

Darn one-percenters always trying to widen the gap.