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

Question

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.
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.
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
Say hello to my little friend.
RFC 2323 FHE-Compliant
Solved!
Go to Solution.

Answer 1

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.
Say hello to my little friend.
RFC 2323 FHE-Compliant