Leaderboard

XML can be tricky because it's refnum-based. Use error wires to force the execution order of the invoke nodes. The following snippet adds an attribute "attr"="1" to the <properties/> element.

Hi Jean, You've hit into one of the things that also puzzled me at first with the AF Attached, you'll find a "fixed" version of your project. Let me explain what's going on here. What's crucially important in your understanding of the Actor Framework, is that LabVIEW objects are by-value, not by-reference (see the NI Whitepaper on LVOOP). So every class wire in your Block Diagrams has class private data clusters flowing through them, following the same data-flow rules that would apply to other wires. Let's have a look at the Actor Core.vi of your Secondary actor: The private data cluster of Secondary.lvclass comes in at the "Secondary in" terminal (top-left), but the wire splits in two branches. The branch labeled [1] goes off into the base class' Actor core, which contains an 'infinite' while loop that processes all incoming messages, and calls the "Do.vi" methods of your message classes. The branch labeled [2] goes into your parallel While loop. So, effectively, the above VI looks like this: What happens if your Secondary actor receives the Write my String message? Well, all this message processing takes place in the bottom While loop! Whatever happens to Secondary's private data cluster there, will stay within that bottom While loop, due to the way data flow works. The "my String" update will never reach the upper loop. All this means that getting data updates from your messages to your Actor Core's front panel is a very fundemantal 'problem' in the Actor Framework. The only way to solve this problem, is to somehow work with references to data, instead. There's two ways to do this: Use a Data Value Reference (DVR). Add a DVR to your actor's private data cluster, and use this DVR to communicate data between the upper while loop and the message processing VIs. (As a sidenote, you should be aware, if not already, that continuously updating your Front Panel like you did in your example project, is not very efficient). Use control refnums to your Front Panel controls and indicators, and store those refnums in the actor's private data cluster before the class wire branches off into [1] and [2]. You can then update Front Panel controls elsewhere in the code, whenever necessary. Strategy 2 is the one I've chosen in the attached sample, and also the one I've been using in my real-world AF project. It's a bit cumbersome, but works very well. I hope this clears a few things up! Best, Onno (Actor Message Learning_fixed.zip)