LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Combining LVOOP DVR with Asynchronous Dynamic Dispatch and Preserve Run-Time Class

Solved!
Go to solution

OK, the title sounds like a cornucopia of LVOOP terms.  But there's a reason.  This is in a way an extension of THIS thread.

 

What I'm doing recently is creating a LVOOP approach to loading Completely Asynchronous UI elements into subpanels.  This I have combined with a global repository for the objects (which are essentially singletons with a UI functionality) which are shared via DVR, thus eliminating a lot of synchronisation headaches).

 

This means that I can ahve a universal framework for launching the UI elements into a subpanel.  The changes made on the Object there are automatically reflected in the global repository.

 

So far so good.

 

What I don't like too much is a combination of two seemingly awkward code constructs I need in order to keep things running.

 

Weird construct 1:

 

I have defined a "Launch UI" function in my parent class which is Dynamic Dispatch (Allowing each object to take care of launching its own UI).  This takes a parent object DVR as a second input which I make sure is of the exact same type as the object type being invoked by using the code shown below.  The ACTUAL Type of both inputs to the launch VI within the IPE are identical.  This is guaranteed because I require each new class to override this function.

DVR IPE 2.png

Here I pass the DVR from outside the IPE to the "Launch" VI but the Object obtained within the IPE retains information required for DD thus ensuring that the VI called for launching the UI is identical to the ACTUAL object type in the DVR.  This works OK and by placing this weird construct WITHIN the parent class, abuse is minimised, it works fine and seems to have no major side-effects.

 

So now we have a VI running asynchronously in the background which belongs to a specific object but has a DVR which it *thinks* is of a Parent Type but, because of the steps taken earlier, is actually of the same type as the object itself.

 

In order to make use of the functionality defined in this actual object type, I need to continuously re-interpret the Object within the IPE as shown below.  Otherwise only the Parent functionality is available.

 

DVR IPE.png

 

If I am accessing only methods of the parent class, then the Preserve functionality is not needed.

 

Is there a more elegant way to do this?  I find the net result of this code and type-juggling to be really useful and much easier to manage than the non-DVR route since the synchronisation issues disappear.  By making the IPE usage near-atomic we remove the chances of deadlock.

 

All editing done in the UI of the asynchronous VI is reflected automatically in any subsequent usage of the DVR.  Even if the DVRs are not shared between VIs, this makes (for me) the headache of synchronisation easier.  If you start expanding this beyond the limits of a single VI, the benefits in Synchronisation become really huge.  You can even have multiple UI objects operating on the same data in the background without extra synchronisation needs.  The only synchronisation required is a global "Data updated" for the object in question whereby the UI elements simply update their indicators and controls from the DVR again.  This is trivial.


Thus I am convinced that the net result of this is very beneficial.

 

My question is if there's a better, safer or more "official" way to do this?

 

I was about to start a new Idea for combining the "Preserve Run time Class" and the DVR Terminal of the IPE so that the casting is done automatically.  We could then have a double input to the IPE, the DVR (of base type) plus the ACTUAL Type of the object but of course returning an error if the types are incompatible.  It would be like an "Imposter" DVR input for the IPE which allows a re-interpretation of the object type.

 

Would all of this go away if we allowed Dynamic Dispatch to work with DVRs?  Probably.

 

Shane

 

Message 1 of 6
(4,299 Views)
Solution
Accepted by Intaris

I agree that removing weird construct #1 probably requires dynamic dispatching on DVRs.  Unfortunately, if you look at the Idea Exchange post on this, there are some nasty subtleties involved in implementing this, so I wouldn't expect it anytime soon.

 

For weird construct #2, you can cast the DVR itself.  Make a DVR constant that refers to the child class, and downcast it before it goes into the IPE.  If you need it to go back to the parent type after the IPE, just branch the DVR wire before the cast and use that as your output wire.

 

Message 2 of 6
(4,280 Views)

As an aside, one thing that raises an eyebrow in construct #1 is that the Launch VI must not try to dereference the DVR, otherwise you'll deadlock.  From what I gather, descendent classes are required to override the Launch VI, so anyone implementing those classes would need to be aware of this limitation.   

Message 3 of 6
(4,273 Views)

Nilaracecrew has the right idea about casting the DVR (using "to more specific class" I'd think).  As Aristos Queue noted here, "If you are wiring the center terminal of PRTC with a constant, something is wrong in your code."

Message 4 of 6
(4,270 Views)

@nathand wrote:

Nilaracecrew has the right idea about casting the DVR (using "to more specific class" I'd think).  As Aristos Queue noted here, "If you are wiring the center terminal of PRTC with a constant, something is wrong in your code."


That's right.  In case anyone reading the thread hasn't seen it before, here's an example.  This uses the Graphic classes found in examples/lvoop, but all you really need to know is that Graphic is the base class, and Circle derives from it.

 

dvrcast.png

 

 

Message 5 of 6
(4,264 Views)


You guys rock!

 

I didn't even think of casting the DVR like that.  Kinds stupid of me but I never would have thought it would work.  Cool.

 

Also, Yeah, the limitation of no IPE in the Launch VI was one I spotted quite early on.  this is why my Launch VI also doesn't accept more data than is absolutely neccessara because a DVR access in that VI will of course cause a lockup.  I have the system so far now that I can have a SINGLE Launch VI (Which is NOT overridden, so the limitation refers to only a single VI now which is certainly better.

 

So again guys, thanks for helping out an old newbie.  I've been around for quite a while, have made many posts but I love the way I just keep learning from others in the Forum.  This is just why I absolutely LOVE it here.  🙂 🙂 🙂

 

Shane.

0 Kudos
Message 6 of 6
(4,259 Views)