how to cast a class to enable it as dynamic parameter?

[agony]

if you call a non-dynamic method of a parent class, the returning object can't be used as dynamic dispatch output, even it is absolut sure, that the object is of the needed type.

same is, if you get the object-data via a reference-call, as in the VI in the attached picture...

there is also the only method shown, I've found, to get it work: unbundle the object and bundle its data again with a dynamic dispatch object as cast-operator.

this method has got disadvantages:

until the class is built up, every change to its properties must be considered in these methods, because the cluster -connection doesn't expand its  connections automatically and for evry new class, these mechanism must be rebuilt individually instead of just copying a template.

the class-cast-operator won't work, because it's output is never usable as dynamic dispatch-operator and so the type-cast-operator does.

any suggestions to solve this in a simple way?

thanks in advance.

[agony]

---

@agony wrote:

[...]

the class-cast-operator won't work, because it's output is never usable as dynamic dispatch-operator and so the type-cast-operator does.

[...]

---

sorry it's late here...
the type-cast-operator doesn't work, because its polymorphic parameters doesn't allow connections from classes.
(I first only remember, that it doesn't work)

[Jarrod_S.]

It is a known limitation with LVOOP that unflattening data into a class can't preserve the dynamic dispatch path. You might consider trying to make a subVI out of the code that unbundles and rebundles the class data and call that subVI everywhere you need to reconstitute your class. I tried that very quickly and it seemed to work (no broken arrow, at least). If so, when you change your class you'll only need to update that one subVI instead of every method that needs this functionality.

Give it a try and post some feedback!

[agony]

I gave it a try and I'm not sure, who's won, LabVIEW or me.

last three days I went to a never-ending chain of various crashes of LabVIEW until I reach yesterday the point of no return.

reproducible crashes with LabVIEW.

meanwhile I've sent NI a (maybe not following the standards, but I have some other things to do here) report of the crash-party.

because I have to solve the issues within the next two weeks, I tried to trace down the occurence of crash, which is not easy, if Windows always tell me, that there's an access-violation and the program  is to be killed...

the problem seems to occure, if LabVIEW wiring-logic (?) thinks, it has an object of type A, but in real it gets an object of type B, which is inherited from A.
now trying to cast it via class-converter or to de-cluster and to re-cluster it, LabVIEW crashes reproducible.

well, meanwhile I think, that LabVIEW's OO is real at most in a beta-stage, at least in 8.21 (I've ssen today, that there's a new version out, but I can't believe, that it's really better there...)

thanks and good night.

[agony]

another short note at re-bundling:

in a sub-class we re-bundle only it's own data, not those of the upper classes.

as a result, we've actual data in the sub-class, but all data in upper classes come from the object, which is used to rebundle the data for valid dynamic-dispatch output.

so it is NOT a solution to just rebundle the data, except if you have no data in the upper class.

there seems to be a long way, before LabVIEWs OO will be usable.

sorry, but I'm really disappointed...