03-27-2013 10:36 AM
I tend to lean towards wanting to find a good By Value solution to this.
I need to get my hands dirty with this framework to get a better feel for what all is going on. There is a lot of appeal here, but I'm up against the steep part of the learning curve.
03-27-2013 12:34 PM
Maybe I'm misunderstanding what you want, but there is a way to communicate with the UI loop and the example demonstrates it - you can use an event to send data to the loop and the actor's queue to send messages to it. If you don't want to deal with many specific events, you could probably send a copy of the actor itself as an event, so you can read the data directly from it, but be aware that a class definition can't have a reference to itself, so you will probably need to make the event data type actor and then cast down when you get the event.
03-27-2013 02:36 PM - edited 03-27-2013 02:37 PM
Hi tst - Thanks for your reply.
What led me here is this: when I first looked at this design pattern, my thought was: I could use this as my "data logger" actor. But things fell apart when I made a message for the filename actor object data and couldn't figure out how to read this in the event loop of the Actor Core.
03-27-2013 02:46 PM
@Nickerbocker wrote:
Hi tst - Thanks for your reply.
What led me here is this: when I first looked at this design pattern, my thought was: I could use this as my "data logger" actor. But things fell apart when I made a message for the filename actor object data and couldn't figure out how to read this in the event loop of the Actor Core.
With my logging actors, I set their file before I call Launch Actor. Is that an option for you? I assume you want to change the file at various points throughout execution, and that's why you're doing it that way?
03-27-2013 03:02 PM
Your assumption is correct. There are no doubt lots of ways to skin this cat...
I wonder if it wouldn't make more sense to just have a "log data" message that takes my waveform as input and everytime it is fired it appends to a data file rather than use this. Idk... I need to learn this framework though because my applications tend to "blow up" on me. I keep telling my boss to buy me a bigger monitor so my VIs all fit on the screen, but he isn't very sympathetic for some reason...
03-27-2013 03:18 PM - edited 03-27-2013 03:19 PM
My solution to this is to use Control References!
Suppose you have a String Indicator for 'File Name' within Actor Core, pass the control reference to the actor object at the beginning of Actore Core execution, before parent Actore Core.vi gets called. This means the private data of the class should have the control reference of the same type. Create a method called 'Update File Name' VI with a string control named 'File Name'. Inside of the VI, unbundle the control reference and then set the input value to the Value property node. (You can also bundle the input to the private data here) Then create a Message VI of 'Update File Name' VI using the Message maker. This way you don't have to think about passing data to Actore Core.vi.
If the goal is just as simple as updating the control or indicator on Actor Core.vi, I believe this is the simplest way.
Hope it helps.
03-27-2013 03:19 PM
@TailOfGon wrote:
My solution to this is to use Control References!
Suppose you have a String Indicator for 'File Name' within Actor Core, pass the control reference to the actor object at the beginning of Actore Core execution, before parent Actore Core.vi gets called. This means the private data of the class should have the control reference of the same type. Create a method called 'Update File Name' VI with a string control named 'File Name'. Inside of the VI, unbundle the control reference and then set the input value to the Value property node. (You can also bundle the input to the private data here) Then create a Message VI of 'Update File Name' VI using the Message maker. This way you don't have to think about passing data to Actore Core.vi.
If the goal is just as simple as updating the control or indicator on Actor Core.vi, I believe this is the simplest way.
Hope it helps.
Actually that does help and it is a really good idea. Thanks!
03-27-2013 03:26 PM
That's what I meant by this paragraph in my first post in this thread
Additionally, I have put references to controls in my class before the branching occurs, and update the value of what I want using that reference. My accessors then become an unbundle to get the reference, then a value property to get the data I want. I don't particularly like this method, but it seems to work.
03-27-2013 03:55 PM
Actually, I like the idea of using the control reference within the object. Imagine you have to change many different attributes of the control within the Actor Core.vi, passing the each attribute to Actore Core will be messy. Having the control reference makes it possible to put everything within method VIs. You can keep the Actor Core.vi clean.
03-27-2013 03:59 PM
@TailOfGon wrote:
Actually, I like the idea of using the control reference within the object. Imagine you have to change many different attributes of the control within the Actor Core.vi, passing the each attribute to Actore Core will be messy. Having the control reference makes it possible to put everything within method VIs. You can keep the Actor Core.vi clean.
Yes, that's what I've done. I'm apparently no good at explaining it though. I know I misused class when I should have said object at least once, which doesn't help.