Jump to content

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


Recommended Posts

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

Link to comment

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

Link to comment

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

Link to comment

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

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.

post-29-1213199423.png?width=400

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.

post-29-1213199561.png?width=400

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.

post-29-1213199645.png?width=400

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

Ben

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.