Error 1448 on "To More Specific Class"

[diarmaede]

Hi All,

LVOOP newbie here, so please be patient with me.

I have set up test code with a parent class, named "Parent" and two child classes, named "Child1" and Child2." See attached images. When I try to use the "To More Specific Class" function, I get LV Error 1448, "Bad type cast. LabVIEW cannot treat the run-time value of this LabVIEW class as an instance of the given LabVIEW class."

Child1 and Child2 both inherit from Parent.

Any help figuring out how to fix my code would be much appreciated.  Thanks in advance.

I know my sample code is not optimized.  I just threw something together to test functionality.

[diarmaede]

I figured it out.

[RavensFan]

Saying you "figured it out" is not the solution.

Think of people in the future who might have the same issue and see your post when they search for the solution.  Post a message giving some information on how you solved your problem.  Then you can mark that one as the solution.

[diarmaede · Accepted solution]

I realized that one cannot feed the "reference" terminal of the "To More Specific Class" function with the parent class.  One must feed the reference terminal with an instance of the child class, which I accomplished through a case structure that outputs whichever child class is required.

The attached code snippet is a drastically simplified version of my solution. Unfortunately, I cannot share my actual code because it is proprietary, but please feel free to contact me if you would like more information.

Best Regards,

[billko]

---

@diarmaede wrote:

I realized that one cannot feed the "reference" terminal of the "To More Specific Class" function with the parent class.  One must feed the reference terminal with an instance of the child class, which I accomplished through a case structure that outputs whichever child class is required.

The attached code snippet is a drastically simplified version of my solution. Unfortunately, I cannot share my actual code because it is proprietary, but please feel free to contact me if you would like more information.

Best Regards,

---

From a "non" solution to a great one.  Thank you for the detailed explanation!  🙂

[Intaris]

Great addition to clear up some of the confusion..... but.....

The cast is completely unneccessary here. The output of the cast function and the output of the case structure are going to be identical. The cast will be a no-op and doesn't bring any benefit to your code because the type wired to the type specifier for the cast function is no longer a child, but parent (because it needs to handle both Child 1 and Child 2. End result is that the IDE wire type entering the case and the IDE wire type leaving the cast are absolutely identical, the cast serves no purpose.

In essence, wiring a single output terminal of a Case with two different children will automatically coerce both (IDE Type, not actual run-time wire type) to the highest common ancestor, the parent.  The case structure actually does what your upper code is trying to do.  This is why the cast is not required in the lower image.

I hope this is just an issue with the demo code.

[Dharani_Rajagopal]

I faced similar issue. Just sharing my observation in this thread might be helpful for others. Type casting does happen but with an error 1448, I ignored the error with simple clear error API. The program still works for me. Not sure there will be any corner cases in future (use with caution).

[paul.r.r]

---

@Dharani_Rajagopal wrote:

I faced similar issue. Just sharing my observation in this thread might be helpful for others. Type casting does happen but with an error 1448, I ignored the error with simple clear error API. The program still works for me. Not sure there will be any corner cases in future (use with caution).

---

You should absolutely NOT do this - error 1448 means that the input type is NOT the child class type. If this is the case, the node will return a default instance of the child. Since you are clearing the error, you have no idea if the class returned here is the typed input, or a default instance child. It might be working for you in your particular use case at the moment, but this is 100% bad coding and should be fixed.