How to check if a class is an interface or a concrete?

[bjustice]

I ran into a situation where I need to return the class hierarchy of an object as a concrete object array.  (If you are curious, this is used in the BlueSerialization toolkit)

The following code snippet demonstrates how I accomplished this.
Unfortunately, I just discovered that this algorithm doesn't work if a class also inherits from an interface class.  (My algorithm here assumes that a class can only inherit from 1 other class.)

Naturally, my immediate question is this:

Is there a graceful NI primitive or mechanism for determining if a given object is an interface class or a concrete class?

If yes, then I could just filter out interface classes in my code here and move on with life.

 

I did find the "Get LabVIEW Class Parent and Member VI information VI.  But, I can't get this VI to work recursively.  On the 2nd loop iteration, this NI primitive returns that results for a base LabVIEW object even though the wire probe shows this as not being a base LabVIEW object.

 

Get Class Hierarchy.vi

[LogMAN]

Interfaces have no private data control, which means you can just check if such control exists in memory.

The original VI is available on GitHub: https://github.com/logmanoriginal/labview-composition ("Is Interface Or LabVIEW Object.vi")

[bjustice]

LogMAN,

thanks for the input.  This certainly works in a pinch.

I was really hoping that there might be something a bit more native.  This also doesn't seem like it would be super fast to me.

[LogMAN]

How fast do you need it to be?

Speaking about native solution, there is

• <vi.lib>\Utility\LVClass\Is Class Not Interface.vi
• <vi.lib>\Utility\LVClass\Is Class Not Interface Without Loading.vi

However, these might not work at runtime.

[bjustice]

ooo, interesting.

One of these isn't available until LabVIEW 2021

 

Edited November 18, 2022 by bjustice

[LogMAN]

Just in case you are looking for a solution that doesn't have to work in runtime, there is this property for class libraries.

[bjustice]

yeah, it looks like the latter VI is doing exactly that.  Opening the library reference, and then using that invoke node.

I suspect that this is slower than your solution, but probably a bit more bulletproof

[LogMAN]

Not sure about speed, but these VIs use features that aren't available in earlier versions.

However, if backwards compatibility isn't an issue, this is probably the most native way to go about it.

As for speed, perhaps caching is an option?

[bjustice]

BlueSerialization is currently LabVIEW 2020.

hmm... okay.  How bulletproof do you think your VI might be?  Would LabVIEW ever be "smart" enough to not load a classes' *.ctl file into memory if it was blank or something like that?  Or perhaps drop it from a build if it were blank?

If you think this is pretty bulletproof, I'll just use this and push a patch to the BlueSerialization library.

I am already cacheing the results, so speed is probably not a huge issue.

[LogMAN]

That is very unlikely. It would turn classes into interfaces, which is a major breaking change.

[bjustice]

Thanks for all the input.  I'll go with this solution

[bjustice]

BlueSerialization v2.3.3 uploaded to VIPM.

I improved the cacheing scheme a bit as well given this new code addition.