LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

To More Specific Class --> error 1448 when loading from LVLIBP

Hi!

 

I'm currently running into an issue when dynamically loading classes:

 

When loading a class using Get LV Class Default Value from using the .lvclass file and casting the object wire using the To More Generic Class everything works perfectly fine.

Using the same class from a built library (.lvlibp) loading unsing Get LV Class Default Value works as well, but To More Generic Class fails with error 1448.

 

Is there some option I forgot to set before compiling the lib? Has anybody experienced sth similar?

 

Using LabVIEW 2011f2 (haven't tried with f1 or earlier)

 

Cheers

Oli

Thanks for supporting the GLA Summit 2021!

GLA Summit 2021
Message 1 of 17
(3,463 Views)

Some additional information:

 

I'm trying to set up a plug in architecture as described in https://decibel.ni.com/content/docs/DOC-19176

 

The example code works on my machine (with minor changes). So I'm currently diving into my own PlugIn Base Class to see what's going wrong...

 

Thanks for supporting the GLA Summit 2021!

GLA Summit 2021
0 Kudos
Message 2 of 17
(3,447 Views)

Oli,

 

just for verification:

Error 1448 states: "LabVIEW:  Bad type cast.  LabVIEW cannot treat the run-time value of this LabVIEW class as an instance of the given LabVIEW class." This is the error you are seeing?

 

If so, i'd expect to have a broken inheritance hierarchy where you try to cast an object to its (missing/broken) parent. I think, in addition to Michael Lacasse's presentation, you should also check out LV Field Journal.

A more general discussion about pitfalls of PPLs can be found here.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 3 of 17
(3,445 Views)

Hi Norbert,

 

thanks for the suggestions; I've already read Nancys article, it might be worth to have a closer look...

 

See you next week in FFB

 

Oli

Thanks for supporting the GLA Summit 2021!

GLA Summit 2021
0 Kudos
Message 4 of 17
(3,443 Views)

Sorry, yes. It's exactly the error you described!

Thanks for supporting the GLA Summit 2021!

GLA Summit 2021
0 Kudos
Message 5 of 17
(3,439 Views)

Dear Oli, 

 

  I'm running into exactly the same issue. Can you tell me how you fix it?

 

thanks,

toto

0 Kudos
Message 6 of 17
(3,385 Views)

Hi toto,

 

sorry for the late answer, been on holiday.

 

Unfortunately I got stuck in the lvlibp hierachies; due to time constraints, I decided to not use this feature, also I find it pretty much annoying. My approach was to merge several lvlibs into one big lvlibp, but it seemed in my case that there were to many crossconnections so all I got was errors when compiling. Coupling and cohesion ....

I guess for the next project, I'll consider these issues right from the start and set up a hierachy, that fits into this constraints.

 

Best Regards

Oli

 

Thanks for supporting the GLA Summit 2021!

GLA Summit 2021
0 Kudos
Message 7 of 17
(3,349 Views)

Hi toto,

 

tihs one might clear the issue up a bit:

 

https://decibel.ni.com/content/thread/12998?tstart=0

 

We#re not the only ones to run into this issue Smiley Wink

 

Best Regards

Oli

 

 

 

 

Thanks for supporting the GLA Summit 2021!

GLA Summit 2021
0 Kudos
Message 8 of 17
(3,323 Views)

I am having the same error. How did you fix it?

 

Thanks. 

0 Kudos
Message 9 of 17
(3,156 Views)

It's a shame, but I haven't fixed it at all. Instead I abandoned the idea of using the plugin architecture and LVLIBP in this particular project.

It was a bit of a nice to hve feature by that time...

 

IMHO, the key to success is to consider all resctrictions / requirements before starting a lib. Trying to apply this on an existing lib is prone to cause problems.

 

 

Thanks for supporting the GLA Summit 2021!

GLA Summit 2021
0 Kudos
Message 10 of 17
(3,145 Views)