LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Accessing Actor Object Data within Event Loop?

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.

0 Kudos
Message 11 of 24
(985 Views)

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.


___________________
Try to take over the world!
0 Kudos
Message 12 of 24
(978 Views)

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. 

0 Kudos
Message 13 of 24
(971 Views)

@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?

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 14 of 24
(965 Views)

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...

0 Kudos
Message 15 of 24
(962 Views)

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.

TailOfGon
Certified LabVIEW Architect 2013
Message 16 of 24
(955 Views)

@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!

0 Kudos
Message 17 of 24
(952 Views)

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.

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 18 of 24
(944 Views)

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.

TailOfGon
Certified LabVIEW Architect 2013
0 Kudos
Message 19 of 24
(938 Views)

@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.

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 20 of 24
(934 Views)