Messaging XControl on Actor Core FP

[Fedor]

I would like to use custom XControl on Actor Core FP. I would like to be able to send messages the Actor from XControl. What I tried to test is to store Actor's Self Enqueuer in the XControl State.ctl. The Enqueuer is stored via call to XControl property. The messages are sent from XControl Facade.vi at particular UI events (say, button push). This works to some extent, but when I open the actor project, all  classes are now locked. The Xcontrol becomes locked as well, as expected, but it remains locked even after Actor's project is clossed. I guess the problem is due to XControl containing a  Self Enqueuer class, which locks the whole hierarchy. It is noActtot clear why it remains locked after the Actor project is closed.

Are there better solutions for XControl -> owning Actor Core comms?

[Fedor]

I did some more testing and it looks like if one includes an enqueuer or message datatype into any part of Xcontrol used in actor core, it locks out all actor classes, even when the actor project is just opened.

One workaround I came up with is to provide Xcontrol with user events it can trigger and have the actor register for these events in event loop send appropriate messages to self, which is kind of lame for many reasons.

[komorbela]

This Idea Exchange link may be useful to let you know that there is no best and recommended solution yet (as much as I know):

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Custom-events-for-XControls/idi-p/1071226

XControls should have the possibility to fire own events. If this would be possible, you should only register for those in the event loop and send self addressed messages.

I think you have found a very good workaround among all the possible workarounds.

[KvZ]

Sound like a similar issue when using the Linked Network Actors (LNAs) between Window Host and RT targets.

LV classes are locked when they are loaded on both targets (i.e. when they are opened in multiple application instances). The host and target share the communication components (LNAs) in this case this causes both class trees to be loaded in both the host and RT target app instances and thus they will be locked.

I'm not that familiar with the XControl executions and if the same rules apply when using application instances but it sure sounds like this is what is causing the locking.

The solution for the LNAs was using a interface actor that would function as a proxy to isolate the LNAs from the target and host trees. Take a look at the Actor Framework on CompactRIO (and Other RT Targets) example to see how Allen implemented this for the RT targets.

For the XControl case if you want to stick to the Actor Messaging schame you need a Proxy Actor that is launched as a nested actor to the actor that contains the XControl. The XControl would communicate with the proxy actor. The proxy actor needs to map the XControl's supported messages to the parent actor specific messages.

This solution will require you to create a child of proxy actor for each specific actor where you what to use the XControl. I would probably change the XContol functionality into an actor and launch this as a nested actor. Then you can use an subpanel control to embed the actor core's FP in your UI where you would have used the XControl?

Hope this helps,

Karsten

[AristosQueue (NI)]

When an XControl is running, it is just like a VI running -- you can't edit any of its subVIs. Well, an XControl is running any time it is on the front panel of another VI. So if you load a VI into memory that uses the XControl, even though that VI is still in edit mode, the XControl itself is now running... and that locks any files on which the XControl depends. In other words, this lock is independent from the "locked when loaded in two projects" problem.

[KvZ]

Ha, ok thank for clearing that up. then using events or a subpanel is the way to go.