An idea to make Class Private Data accessible to helper loops

[komorbela]

Thanks for the reply! You are definitely more of an expert than I am I still don't exactly know why it happens but I fully trust your experiences.

Based on that not using an Event Registration Refnum in multiple event structures is a rule, I refactored the project again. Now the User Event creation happens in the PreLaunch Init (executes once) but the registration happens in a separate dynamic dispatch VI in the Actor Core (executes twice - 1x in parent, 1x in child). The Shutdown is back to it's original place in the Actor Core as now we unregister using separate Event Registration Refnums.

P.S.: the "This VI" ref is still overwritten, so it should be used with caution.

[LVB]

Just throwing out an idea I had during the CLA summit.  Wouldn't it be nice if LabVIEW could bind a front panel indicator (via control refnum) to a user event?  It would eliminate a lot of the "UI boiler plate code" required on the Actor Core block diagram.

[tst]

What do you mean by "bind"? You seem to indicate that you would have code for this, and you can already do that today in any number of ways.

If you don't want to have code, there's no reason in principle you can't have code which will parse a FP and connect controls on it with user events, going either way.

Can you give a mockup of the feature?

[Todd_Lesher]

2013SP1 known issues includes a reference to using objects as event data. It's safe, except in ppls:

http://www.ni.com/white-paper/14490/en/#320485_by_Category

Jack D's source from that presentation is here:

https://github.com/wirebirdlabs/LabVIEW-User-Events-Tips-Tricks-and-Sundry

Branching registration refnum is shown to be bad in this VI:

"04 - Demonstration - Effect of Branching Event Registration.vi"

[AristosQueue (NI)]

fairlyFunctional:

It has been a long week with the Americas Certified LabVIEW Architect Summit and I'm not up to typing out why I would never program the way you propose. As a shortcut to my usual practice of trying to explain why I would shy away from something, I'm just going to propose the alternative...

Instead of copying the actor using your User Event, can you just post the Message in the User Event and let the event loop hold onto whatever data it needs (not the actor itself, but just the UI data)? Essentially, let the UI event respond to the message the same way you're letting the actor respond to the message? It might even be that you don't need to have any state in the actor itself at that point because all your data is in the event loop.

-- AQ

[David_Staab]

AristosQueue wrote:

Instead of copying the actor using your User Event, can you just post the Message in the User Event and let the event loop hold onto whatever data it needs (not the actor itself, but just the UI data)?

This is how I've integrated some of my non-AF actors into an AF application. It works well, despite the unhappy redundancy of forwarding messages to yet-another-FIFO.

[dsavir]

I dislike using snapshots, as we pass code around a bit and it's only a matter of time until someone changes something in the snapshot and expects the actor data to change...

At the moment I'm using DVRs for internal data that needs to change (i.e. "State") and GUI references for FP data that needs to update (i.e. Intensity Graph). I also have large comments stating that the other data cannot be updated via message 

AristosQueue's idea is much more elegant, but I simply don't have the motivation for handling another queue . I'm think that after more time on the AF I'll probably find it more intuitive.

[jfazekas]

I am working on my first AF project in LV2017.  I have created an Actor that polls the serial port in a helper loop and sends parsed messages to the caller.  If I need to change the polling behavior (like baud rate, or end-of-frame delimiters) a message needs to be sent to helper loop.  I understand the method mentioned above using a registered event.  However, the comment in another post haunts me:

"The Actor Framework already gives you a producer-consumer relationship without having to build your own queues. That is the point of the AF messaging system."

Does the Actor Framework provide a mechanism to send messages to a helper loop, or must I build my own queues or registered events?  Thanks!

[Taggart]

There is no built-in way to communicate with helper loops.  You are on your own for that.

[p4keal]

jfazekas wrote:

I am working on my first AF project in LV2017.  I have created an Actor that polls the serial port in a helper loop and sends parsed messages to the caller.  If I need to change the polling behavior (like baud rate, or end-of-frame delimiters) a message needs to be sent to helper loop.  I understand the method mentioned above using a registered event.  However, the comment in another post haunts me:

"The Actor Framework already gives you a producer-consumer relationship without having to build your own queues. That is the point of the AF messaging system."

Does the Actor Framework provide a mechanism to send messages to a helper loop, or must I build my own queues or registered events?  Thanks!

---

I think in your case some events for changes of parameters should be the best solution.

If you want to get a snapshot from your internal actor state, You can define a child of reply message and send it from the helper loop. An example and AristosQueue's justified criticism for this You can find here: https://forums.ni.com/t5/Actor-Framework-Discussions/Access-to-internal-actor-data-from-its-own-acto...
So be aware of complications of this approach.