Subactor in a subpanel

[Oli_Wachno]

testingHotAir schrieb:

...
In my system, I have a "controller" that implements control over the subpanels.  Any subactor can register a subpanle it owns, and any subactor can request a subpanel by sending the controller its refnum.  Currently, inserting and removing subactors is handled by the controller. 

Am I correct in my thinking that there would be just as many messages exchanged doing it my way vs having the controller send a message with the subpanel reference?

If I understand you correctly, your sending more messages, since you have implemented more functionality.

Im my case, the Actor owning the Subpanels just sends Embed (containing SubPanelRef) and Remove-Messages to the SubActors

[Oli_Wachno]

mthimm1 schrieb:

...

Why do you think that the information architecture is difficult? Is there some advice for me where I should be careful?

If you really want to minimize coupling, you'll eventually have to implement zero-coupling messaging. At least I ended up like this. Took some efforts, but it is working fine

[mthimm1]

testingHotAir schrieb:

Am I correct in my thinking that there would be just as many messages exchanged doing it my way vs having the controller send a message with the subpanel reference?

Maybe, but IMHO the subactors refnum is to sensitive information to send somewhere. I fear that my successor in my project wants to choose the easy path, that one which leads to the dark side, by manipulating the FP directly.

Your software gets older with the time and after a few decades nobody knows anymore, that you habe to send a message to the subactor instead of accessing the vi reference.

[Jonzarwal]

Hi,

I often use AF to define UIs (for dialog boxes or subpanel VIs for instance), and after several tries, I use the same solution than Oli_Wachno, mainly because I don't want to expose the VI core references.

So with the generic UI actor, I can implement the  "Embed in there message" or other stuff that I want any screen to be able to do.

I don't know if i should open a new topic for that, but i have a question related to all that.

We use OOP and AF because we are lasy and it's easier to maintain the code.

But here, even with the generic actor, it's always a pain to define a new screen.

You have to create a new actor and inherit from the generic (OK, easy with LV2015).

Then override the core.

Then register the VI reference in the private data.

Then create a parallel event loop.

Then implement your special system to stop this loop (UE, local variable, whatever).

Then maybe adapt the properties of the VI.

And then you are ready for the specific work you have to do for this sub actor.

Do you all proceed with this steps (very annoying repetitive task) each time? Any idea, solution?

Do you think any scripting, or template is usable here?

[wrkcrw00]

I have yet to try it myself, but the Project Provider can be setup to do

exactly what you're talking about. I have the same burden every time I

create a UI actor, but I plan to use Project Provider to automate all the

tedious repetitive stuff.

Jason A Smith

Principal Systems Engineer

EO/IR Test Solutions

Space and Airborne Systems

Raytheon Company

+1 (424) 367-9095 (mobile)

+1 (310) 204-9338 (pager)

+1 (310) 616-1481 (office)

Jason_A_Smith@raytheon.com

2000 E EL SEGUNDO BLVD.

EL SEGUNDO, CALIF. 90245 USA

www.raytheon.com

This message contains information that may be confidential and privileged.

Unless you are the addressee (or authorized to receive mail for the

addressee), you should not use, copy or disclose to anyone this message or

any information contained in this message. If you have received this

message in error, please so advise the sender by reply e-mail and delete

this message. Thank you for your cooperation.

From: Jonzarwal <web.community@ni.com>

To: wrkcrw00 <jason_a_smith@raytheon.com>

Date: 04/07/2016 08:32 AM

Subject: - Re: Subactor in a subpanel

NI Community

Re: Subactor in a subpanel

created by Jonzarwal in Actor Framework - View the full discussion

Hi,

I often use AF to define UIs (for dialog boxes or subpanel VIs for

instance), and after several tries, I use the same solution than

Oli_Wachno, mainly because I don't want to expose the VI core references.

So with the generic UI actor, I can implement the "Embed in there

message" or other stuff that I want any screen to be able to do.

I don't know if i should open a new topic for that, but i have a question

related to all that.

We use OOP and AF because we are lasy and it's easier to maintain the

code.

But here, even with the generic actor, it's always a pain to define a new

screen.

You have to create a new actor and inherit from the generic (OK, easy with

LV2015).

Then override the core.

Then register the VI reference in the private data.

Then create a parallel event loop.

Then implement your special system to stop this loop (UE, local variable,

whatever).

Then maybe adapt the properties of the VI.

And then you are ready for the specific work you have to do for this sub

actor.

Do you all proceed with this steps (very annoying repetitive task) each

time? Any idea, solution?

Do you think any scripting, or template is usable here?

Reply to this message by replying to this email -or- go to the message on

Community

Start a new discussion in Actor Framework by email or at Community

[drjdpowell]

Comments:

If you send "Insert yourself in this subpanel" messages and insert multiple FPs in the same subpanel, consider including some 'cancellation' ability, to avoid the following race condition:

Use picks A

Tell Actor A to insert itself (but Actor A is busy handling another message)

User quickly picks B

Tell Actor B to insert

Actor B inserts

Actor A inserts

You can use a DVR of the subpanel reference to allow cancellation of the request to A.

If, instead, one wanted to have some central manager control all FP references (which I usually do), then you can protect the VI reference by encapsulatimng it in a class that only exposes the ability to insert in a subpanel.

BTW to Jonzarwal,

You don't have to create a new actor for each new front panel.  There are other techniqes just using a regular subVI.

[auspex]

mthimm1 wrote:

Oli_Wachno schrieb:

Change perspective .... Controller can send the SubPanel Reference to the subactor with an "Embed in there message" no need to expose the VI Refnum

Yes! Thank you! This was the idea I was looking for! This is brilliant. Like this the actor core vi ref stays hidden in itself. I would have had a very bad feeling if somebody later just would have accessed the child vi FP instead of sending a message.

I will do it in that way.

Why do you think that the information architecture is difficult? Is there some advice for me where I should be careful?

The actor core VI ref does not stay hidden. The actor with the subpanel can retrieve it through the "Inserted VI" property of the subpanel. As far as I can tell, there is normally no way for the VI within a subpanel to get a refnum of the VI that owns the subpanel, so passing the subpanel refnum to the child actor is exposing the parent actor's VI when ordinarily the parent would be protected from the child.

I'm using a base class for the child actors which provides ways for its subclasses to integrate with the parent actor. The base class has an array of VI refnums to which subclasses are expected to provide their Actor Core VI refnums using an "Add Panel" method. This method is called in each subclass's Actor Core before calling the subclass's parent's Actor Core. When the actor is fully launched, the base class can provide the array of subclass Actor Core VIs to the parent actor, and they will be sorted from lowest subclass to base class (or the reverse). The child actors can be written to provide a simple user interface for day to day use and another one for debugging. With some established convention, the parent actor can then select the appropriate interface. The VI refnums are only used for putting a child actor interface into the parent actor subpanel; all communication between parent and child actors is by message passing.

The base class also provided events for subclasses (not the parent actor!) to use. These are created in its Pre Launch Init. Each subclass can register for these events, but I have to rely on courtesy for none of them to tamper with the event refnums. Since it is common, the base class provides a Stop event which is generated with high priority in the its Stop Core override. I suspect there's a race condition between that event being received by all subclasses (which should unregister from it) and the event being destroyed, but it hasn't been a problem yet.

[mthimm1]

You are right, the FP the subactor inserts to the vi is not fully hidden and this is a problem for me. I did not now, that you can retrieve the embedded vi ref since I never used it.

I am using a similar strategy as you to provide some base functionality. I also have a general base class which iherits directly from the AF actor class and some specialized base classes which inherit from the general one, but add extra functionality. I even have also a stop event. In my project it is also used to provide a termination condition for the event loop in actor core.

I will put the functionality of removing and inserting in some parent class, to minize the possibility of unauthorized access by the caller. Nevertheless I you made me some bad feelings.

[Oli_Wachno]

Re-opening this thread to add the following link:

How to Embed a Nested Actor's Front Panel into a Caller's Subpanel