LVOOP Example Code

[ahull]

Action is the Class.

[Aristos Queue]

You missed a key trick -- that enum is a maintenance hazard, and there's an easy way to avoid changing the mechanical action of "Plus 2". Oh, and I renamed your "Data.lvclass" as "DoNothing.lvclass" since its job really wasn't to load the data but just to give the queue something to do on those events. See attached file.

You can actually get rid of the Value Changed event case and the shift registers entirely by just moving those FPTerms outside the event structure -- I didn't make that change in this revision. I could've gone a lot further in the refactoring, but I figured this revision highlighted the enum improvement the best.

Download File:post-5877-1230873647.zip

[ahull]

The modifications you made were the original intent.

I find that this architecture is difficult to implement in "real" applications. The data operated on, in this example, has very specific input and output. When the data operated on is unique the implementation becomes more challenging, similar to implementing automatic selection of polymorphic vi's.

[Daklu]

QUOTE (Aristos Queue @ Jan 1 2009, 09:20 PM)

You can actually get rid of the Value Changed event case and the shift registers entirely by just moving those FPTerms outside the event structure...

Since they are all Value Changed events, I'll make the bold assumption you're referring to the X and Y Value Changed event. :laugh:

I'm wondering why you suggested that particular refactoring. How would the compiler treat the current code differently if we pull the x and y terminals out of the event structure? I assume it would do as coded and assign the front panel value to a memory location on every loop? Any idea how that overhead compares to the overhead of monitoring an event?

I only ask because I tend to use these manual "optimizations" as well since I don't know smart the compiler is and from what I've read it's "better" to put something like changing the x and y value in an event rather essentially polling them on every loop. (Obviously there will be very little performance difference in this particular example. It's more a question of style and principles.)

[Aristos Queue]

QUOTE (Daklu @ Jan 2 2009, 07:55 PM)

Since they are all Value Changed events, I'll make the bold assumption you're referring to the X and Y Value Changed event. :laugh:

yes.

QUOTE

How would the compiler treat the current code differently if we pull the x and y terminals out of the event structure?

It's not the compiler. If we pull those out, we can get rid of the "DoNothing.lvclass" entirely. And the loop wouldn't wake up to try to do the "Enqueue Element" just because you typed in new numbers.