Accessing LVOOP "thingies" in prallel loops (part 2)

[LAVA 1.0 Content]

I want to be able to update a picture control that represent a set of objects using a "update" method in one loop while handling user events for those same objects in another loop.

I slapped together an action engine that uses a SR to store an array of the objects and then added actions that corespond to the methods. So far it seems to work fine but I have to ask;

"Am I defeating the purpose and intent of LVOOP by using an Action Engine to store the LVOOP objects?"

I ask because I have often read LVOOP as being an alternative to AE's and am concerned I am failing to get the whole LVOOP idea and am "just putting lipstick on a pig".

Your thoughts?

Ben

[jgcode]

QUOTE (neB @ Jun 11 2008, 10:04 PM)

"Am I defeating the purpose and intent of LVOOP by using an Action Engine to store the LVOOP objects?"

I ask because I have often read LVOOP as being an alternative to AE's and am concerned I am failing to get the whole LVOOP idea and am "just putting lipstick on a pig".

This is one of my answered questions... keen to here veteran advice....

[Omar Mussa]

QUOTE (neB @ Jun 11 2008, 07:04 AM)

"Am I defeating the purpose and intent of LVOOP by using an Action Engine to store the LVOOP objects?"

I assume that by Action Engine you mean you're using a functional global inside your LVOOP object. What it sounds like you are doing is trying to create a By Reference framework. Search for LVOOP and By Reference or ByRef. There's been a lot of discussion on LAVA related to this topic.

The short answer, creating ByRef objects using LVOOP (ByVal) objects is not defeating the purpose of LVOOP. There is even a shipping example that shows how to do it (ReferenceObject.lvproj).

[LAVA 1.0 Content]

QUOTE (Omar Mussa @ Jun 11 2008, 11:19 AM)

I assume that by Action Engine you mean you're using a functional global inside your LVOOP object. What it sounds like you are doing is trying to create a By Reference framework. Search for LVOOP and By Reference or ByRef. There's been a lot of discussion on LAVA related to this topic.

The short answer, creating ByRef objects using LVOOP (ByVal) objects is not defeating the purpose of LVOOP. There is even a shipping example that shows how to do it (ReferenceObject.lvproj).

Thanks Omar,

I can see how that can be used if I can create my object at the start then fork the wire to feed two loops.

In my case, objects will be coming and going. In the end I think I will end up with at least three parallel threads running, one for each of;

1) read from real-world source and update each object with a new value

2) Keep screen updating at 10 Hz

3) GUI, user can add new or toss old objects. Also can change attributes of any widget.

I am attaching a zip of what I have so far (warning memory leak is due to how I implemented the re-drawing. Will fix this latter).

This is what I have so far. My top level VI has two loops, 1) Screen updates, and 2) Handle "mouse down" events to add new widgets.

The screen updates use the AE to invoke "Update Image" methods and widget that have a new image get re-drawn then picture is updated.

When a mouse down event fires a new widget is added to the collection inside the AE and a the Image Change flag is set true.

So I am still wondering if I am going the wrong way with this.

Ben

[Aristos Queue]

QUOTE (neB @ Jun 11 2008, 09:04 AM)

"Am I defeating the purpose and intent of LVOOP by using an Action Engine to store the LVOOP objects?"

No. It is perfectly legitimate to store a LVClass in any functional global, including action engines.

QUOTE

I ask because I have often read LVOOP as being an alternative to AE's and am concerned I am failing to get the whole LVOOP idea and am "just putting lipstick on a pig".

What I suspect you've read is my ravings about a better way to write the action engine itself using LVClasses. That new, revised action engine still stores data just like the ones you've written for years, and it can store any LV data, including LV classes. But it is more extensible and reusable.

If my guess is right, you think you've read "LVOOP is an alternative to AEs" when what I have said is "LVOOP provides an alternative implementation for AEs".

[LAVA 1.0 Content]

QUOTE (Aristos Queue @ Jun 11 2008, 03:49 PM)

No. It is perfectly legitimate to store a LVClass in any functional global, including action engines.

What I suspect you've read is my ravings about a better way to write the action engine itself using LVClasses. That new, revised action engine still stores data just like the ones you've written for years, and it can store any LV data, including LV classes. But it is more extensible and reusable.

If my guess is right, you think you've read "LVOOP is an alternative to AEs" when what I have said is "LVOOP provides an alternative implementation for AEs".

I can't express in words how happy I am to read your reply. There are tears welling up in my eyes because I am actually starting to "get it"! Maybe this emoticon will help illustrate.

http://lavag.org/old_files/monthly_06_2008/post-29-1213214149.gif' target="_blank">

Thank you, Thank you, Thank you!

Ben