Give us some way of FORCING a specific LVOOP cast

[Intaris]

This ties into a recent post I made on the NI Forum HERE.

I have already run into this problem a few times.

Somewhere in my code I have a process returning an object of a particular class which does not have the exact same type as a dynamic dispatch input.   My post above shows a workaround for this (which, if it wasn't so horrible it'd be funny).

I've run into similar problems where the object is being passed via Queue or Event where I have to pass the Objects as a parent class to enable portability but where I KNOW the only source of the data is a VI sending an object of EXACTLY THE SAME TYPE as the dynamic dispatch input.

A normal "to more specific class" does not work presumably because the resulting object COULD be a further sibling of the required object, thus breaking any dynamic dispatch tables.

Up to now I've had to write a class member to take the existing object and another object of type parent and make a cast and update the values manually which is really annoying because it requires each and every child class to implement this (and make use of the parent function).

So what I'd like is a function to allow an EXACT cast of an LVOOP object so that I can still satisfy the Dynamic Dispatch requirements without having to have a piece of code for each and every child class created.  If the Object classes don't match EXACTLY, return an error and the contents of the object used for the cast.

Shane.

[Intaris]

The method shown above actually enables returning a DIFFERENT object type on the output terminal than the input terminal even though the terminals are both set to "Dynamic Dispatch".

As such, an official method would be certainly more robust.

Message Edited by Intaris on 06-17-2009 08:22 AM

Message Edited by Intaris on 06-17-2009 08:23 AM

[AristosQueue (NI)]

> The method shown above actually enables returning a DIFFERENT object

> type on the output terminal than the input terminal even though the

> terminals are both set to "Dynamic Dispatch".

It better not. That's why FPTerminals for dyn dispatch are required to be at the top level of a diagram. The FPTerminal is always the last thing to execute, so any property nodes for Value have already fired, and the return value is guaranteed to be the original type. If you're seeing otherwise, that's a severe crash-causing bug because the returned object will be traveling on a wire that doesn't support its type.

[AristosQueue (NI)]

I threw my Kudos on this idea. It's one that I've already been working on solving.

[Intaris]

Well It seems to essentially break the DD n the VI I have implemented.

I can mail you an example if you want.  I HAVE put a check in place with the "class path" VI to make SURE they are the same, but it is possible to get around the Dynamic Dispatch check this way.

It's all got to do with the Property Node being executed AFTER updating the output Dynamic dispatch Terminal.

[Intaris]

Already working on solving, Kewl!

[Intaris]

AQ, I've posted an example (HERE) of the Override I was referring to ont he NI Forums (THREAD LINK).

[AristosQueue (NI)]

> The method shown above actually enables returning a DIFFERENT object

> type on the output terminal than the input terminal even though the

> terminals are both set to "Dynamic Dispatch".

I have confirmed this is a bug with 8.2, 8.5, 8.6 and the next LV version. Unfortunately, we're too late in the release cycle to fix it for the next release, so it will be addressed for the release after that. Thanks for letting me know about this. I've got the compiler team working on it already. This worked at one point in LV8.2 before release, but it seems to have been removed before release and has never been fixed since then.

[Intaris]

But we'll have some way of forcing the LVOOP class by then, right........ please?

Message Edited by Intaris on 06-23-2009 09:57 AM

[Intaris]

Am I to understand that THIS will allow us to force a specific LVOOP cast?

http://zone.ni.com/devzone/cda/tut/p/id/9386#toc2

I'm referring to the "Preserve Run-Time Class.vi" part....

Message Edited by Intaris on 07-31-2009 12:54 PM

[Intaris]

I just tried it out and it seems to allow an Object wire which does not originate from the input terminal of a dynamic dispatch VI to satisfy the requirements for the dynamic dispatch output which "to more specific class" could not.

What exactly is the "Preserverun-time Class.vi" doing that the "to more specificclass" does not?

But this still allows conversion to the target Object OR CHILDREN of the target object.....  Can we not have an option to force an EXACT cast?  We can always compare the class paths I suppose......