From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with To More Specific Class

I have the following snippet, which is trying to use the 'To More Specifc Class'.  The 'Red' class inherits from the class from the green VI.

ToMoreSpecific.png

 

 

The reference probe shows:

InputClass.png

 

Whereas the red target shows :

MoreSpecofoc.png

 

 

When I run this I get error 1448:

LabVIEW: Bad type cast. LabVIEW cannot treat the run-time value of this LabVIEW class as an instance of the given LabVIEW class.

0 Kudos
Message 1 of 7
(2,691 Views)

Most likely the object coming out of VI 6 is a subclass of the Green class, but something other than the Red class.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 2 of 7
(2,686 Views)

So the object coming out of VI 6 is DataClass_cham.lvclass, my red class is CameraData.lvclass which inherits fram that DataClass class.  I thought that this code would assign that incoming reference to the DataClass class

0 Kudos
Message 3 of 7
(2,682 Views)

To More Specific Class (TMSC) only operates on the wire. Let's say you have a class hierarchy of the following:

 

-Instrument

-Power supply

-Agilent power supply

 

If you drop a constant of type Instrument on the diagram, you cannot use TMSC to convert it to Power supply or Agilent power supply. TMSC is used when you have a parent class wire that is, under the hood, a child class.

 

You must create the object of the child class from the beginning. For the example above, you must drop a constant of Agilent power supply at the start, not either of the above.

 

An example of when this might be used: let's add a Korad power supply class that also inherits from Power supply. The user is able to select which one he needs at runtime, so you use a case selector. In one case you have an Agilent power supply class constant and in the other you have a Korad power supply class constant wired to the same output tunnel. This tunnel will autoconvert to a Power supply class wire. You cannot, at this point, use Agilent power supply VI's on the wire unless they override a VI in the Power supply class.

 

To use a method that's ONLY on the Agilent power supply class, you would have to use TMSC to convert the wire type from Power supply to Agilent power supply. Note that this only changes the wire type, not the underlying object itself!! This is very important to understand.

 

Aside from all that... often, needing a TMSC at all can be a "code smell" that means you should refactor your code to use Dynamic Dispatch. It's certainly required for specific applications, but you should always try to use Dynamic Dispatch when you can. Usually the applications that require TMSC are a bit more advanced than basic class design.

Message 4 of 7
(2,672 Views)

@jmaslek wrote:

So the object coming out of VI 6 is DataClass_cham.lvclass, my red class is CameraData.lvclass which inherits fram that DataClass class.  I thought that this code would assign that incoming reference to the DataClass class


The class of the wire, and the class of the object passing through the wire aren't necessarily the same; the object passing through the wire can be a

descendant of the wire class.  Because you're casting the wire to the Red class, the object passing through the wire must be a Red class object or a descendant of the Red class.  Anything else will through an error.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 5 of 7
(2,624 Views)

The only usage of "To more specific" is if you need to access a method that doesn't exist in the parent class. It logically follows that the object must be of that class originally then ...

When would this be useful?

Let's say you have some different setups for instruments with different connector panes. This prevents dynamic dispatch, so these methods are class unique.

In this case it'd be useful to specify a class to use the right connector pane. (Or you make all methods have a Variant input and a class specific type def and avoid the problem ...)

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 7
(2,566 Views)

@jmaslek wrote:

So the object coming out of VI 6 is DataClass_cham.lvclass, my red class is CameraData.lvclass which inherits fram that DataClass class.  I thought that this code would assign that incoming reference to the DataClass class


This looks like maybe the opposite of what you said in your opening post.

Just be careful about what you're trying to do. This might help:

Example_VI.png

 

Here we see that

  • I can make a Child object into a Parent (but this is boring, and would be better accomplished by "To More Generic Class")
  • cannot make a Parent into a Child. In the quoted response above, it sounds like that could be your problem (also based on the class names you gave)
  • For the intended use of To More Specific Class, I can take a Child object on a Parent wire and use the node to get the Child datatype out (see that the wire colours at the outputs of the top and bottom are the Parent and Child colours respectively).

GCentral
Message 7 of 7
(2,536 Views)