Preserving run-time class with cluster of objects

[CharlesB]

I love how useful is the "Preserve runtime class" node when I wire an object to a more generic subVI, and not having to downcast it after... (first snippet is the subVI, and second is how I use it)

 

 

But how to make it work with cluster of objects?

 

I tried this in the SubVI:

 

But no success: unbundling after my subVI call gives me the base class, and I have to downcast it.

 

 

Any thoughts on this problem?

[drjdpowell]

I’m afraid the "terminal thralling†(as NI calls it) only works on LVOOP objects directly.  Not even arrays of objects, which is what I would particularly like.

BTW, “Preserve Run-Time Type" is usually not necessary, as the compiler can trace the object identity through the subVI.  Only if the output type could change, do you consider forcing it not to with â€œPreserve Run-Time Typeâ€.

[CharlesB]

I was expecting this type of answer... Keeping type for objects in arrays and clusters wouldn't be too hard, I guess!

 

Thanks

[Aristos Queue]

In 8 years, that's the first time I've heard the cluster/array request. It comes in sometimes for DVRs and for VI Server class refnum types, but infrequently enough that NI has never acted on it.

To be clear: it is doable, there just hasn't been pressure to do it.

[shoneill]

In 8 years, that's the first time I've heard the cluster/array request. It comes in sometimes for DVRs and for VI Server class refnum types, but infrequently enough that NI has never acted on it.

To be clear: it is doable, there just hasn't been pressure to do it.

Eh?

 

This seems like a weird construct to me.  I'm not sure what to think of this.  Makes me think of a limited set of generic datatypes.

[drjdpowell]

In 8 years, that's the first time I've heard the cluster/array request. It comes in sometimes for DVRs and for VI Server class refnum types, but infrequently enough that NI has never acted on it.

To be clear: it is doable, there just hasn't been pressure to do it.

 

I made the request for it to work for Variants, which would include the cluster support CharlesB wants, and also support mixed clusters of objects and primitive types.

[shoneill]

I made the request for it to work for Variants, which would include the cluster support CharlesB wants, and also support mixed clusters of objects and primitive types.

Well, reading that thread I have to re-quote AQ

 

Thus I see this as a poor stop-gap for generics, and not a sufficient stop gap to be able to get new features any time sooner

 

 

That's exactly what went through my head when reading this post on LAVA.  I'm also a bit confused about generics being a thing for the far future versus his claim in this thread about it being do-able..... Surely it's one or the other or has something fundamentally changed since then?  This is the part I am most confused over.  Could it be that generics are soon to enter the LabVIEW world?

[hooovahh]

Could it be that generics are soon to enter the LabVIEW world?

I sure hope not.  Have you used XNodes?  They have all the functionality of generics and a ton more.  Heck I'm sure the original question could be solved with a simple XNode.  I want type adaption that is better than polymorphics.  But I also want custom help, icons, growable nodes, custom right click menus, and edit time scripting.  

 

The good news is this technology has been developed and used by NI for quite some time.  The bad news is they aren't ready to support it as a product.  When scripting was official I was ecstatic.  If / When XNodes are supported as a product I will likely drop all other work I'm doing and focus my work on supporting and releasing tools that I've wanted to write and make official for years.  Few things could NI do today that would make me happier. 

[CharlesB]

Could it be that generics are soon to enter the LabVIEW world?

 

Generics are maybe an solution to drjdpowell's request, but as for mine the compiler just needs to be a little smarter to guess what type of object is in my cluster. In this case it's just compile-time type determination.

 

In 8 years, that's the first time I've heard the cluster/array request. It comes in sometimes for DVRs and for VI Server class refnum types, but infrequently enough that NI has never acted on it.

To be clear: it is doable, there just hasn't been pressure to do it.

 

The fact that this type of request rises may be a good sign that LabVIEW users are now more mature and at ease with object-oriented programming, and thus more demanding

[shoneill]

Generics are maybe an solution to drjdpowell's request, but as for mine the compiler just needs to be a little smarter to guess what type of object is in my cluster. In this case it's just compile-time type determination.

 

Generics are also a compile time determination.  This is why the suggestion is basically asking for generics.  This "little smarter" is pretty much what generics have to offer.

 

This is in contrast to LVOOP which has an unknown type (but known ancestry) at compilation.  Variants (or at least their contents) are also unknown at compile time.

I sure hope not.  Have you used XNodes?  They have all the functionality of generics and a ton more.  Heck I'm sure the original question could be solved with a simple XNode.  I want type adaption that is better than polymorphics.  But I also want custom help, icons, growable nodes, custom right click menus, and edit time scripting. 

 

I've yet to dabble in XNodes.  While I share your desire for these advanced features, I don't want NI doing another quick hack whose negative side-effects we'll be fighting against until the end of time.  Xcontrols anyone?  That's a great example of a cool idea just implemented wrongly because they looked at the problem with far too narrow a view. (This is simply my personal opinion on XControls)

 

At least for the type adaption  part of your request, that's exactly what generics should solve.  The others are different topics.  AFAIK, Xnodes will never be made public and I'm sure NI has their reasons for that.

[ShaunR]

simple XNode.

No such animal

[Aristos Queue]

Automatic type propagation does not require a different code segment and a potentially different block diagram. Generics do. Auto type prop doesn't make any changes to the block diagram -- poly VIs do not shift, wire types do not change, charts/graphs are untouched, etc. Generics actually produces a whole new VI with the new type running through it.