Error 1498

[CoastalMaineBird]

LV2018 SP1

For reasons unknown, I am now getting an Error 1498 at GET LV CLASS DEFAULT VALUE.

I am dynamically loading a PPL containing a class, and trying to extract the class and use it.

Some change to the class has apparently triggered this new behavior but the error message is useless.

This happens in the DevSys as well as in a built app.

The weird thing is, if I hit the breakpoint above and step thru, I see the error appear.  If I quit the main program and then run this VI by itself (using the exact same path), it succeeds without error.  Therefore the error is sensitive to context - but what ?

How do I debug this?

EDIT: I should point out that what's in the PPL file is a class that is a descendant class of DFV Module, not the DFV Module class.

Still, this has worked before. 

And the error occurs BEFORE trying to cast the class anyway.

[CoastalMaineBird]

New information: the DFV MODULE class is a GRANDPARENT class.

There exist two CHILD classes and about 8 GRANDCHILD classes.  It is the GRANDCHILDREN I need to load - the ancestors are just frameworks.

I can load some of the grandchildren OK.

And after that, I can load the one that FAILED  OK.

"Context" is key, it seems.

[CoastalMaineBird]

Hmmm. Getting closer....

Given the GRANDPARENT, PARENT, CHILD relationship, it ALWAYS fails when I load a particular child first (after startup).

But the PARENT class is not included in the project, nor referenced by ANYTHING except the child itself.

If I include the PARENT class in the project (just in the explorer ), then the child will load OK and run OK, but break when I quit.

(In spite of the fact that it just ran, it now reports broken).

If I start over (restart LV), then I can load a DIFFERENT child OK, and then load the above child OK.  But still it breaks on quitting.

[CoastalMaineBird]

OK, here's the solution:

The 1498 was cured by having a reference to the PARENT PPL in the main program.

Without it, loading the CHILD couldn't find the PARENT (even though the child references the parent) and that led to an error.

I don't quite understand it, but the cure is the cure.

The "broken on quitting" problem was that LabVIEW had corrupted its own Build Spec (it does that from time to time). Re-creating the build spec fixed that.

Thanks for listening!

[CoastalMaineBird]

No - I should have realized that it wasn't that simple.

Rebuilding the whole thing from scratch brings the 1498 back again.

[CoastalMaineBird]

It's got something to do with a context that I don't understand.

Now EVERY grandchild shows the same behavior: 1498 when trying to GET DEFAULT CLASS and the main host is BROKEN after quitting.

I now have an instance of the PARENT class in the main host.  No good.

There's a key in the fact that, running from the host, the 1498 occurs, but yet after I quit the host and run that same subVI by itself, with the same path coming in, it succeeds.

But I can't see what the key is telling me, and the error message is useless "There are errors in the library" ? ? seriously?

[Ficare]

Hi Steve,

I have a similar problem as the one you described in your posts... Did you finally found a solution ?

BR

Philippe

[CoastalMaineBird]

Did you finally found a solution ?

No.  It went away for some reason, and turned into a CRASH problem (opening a LVLIBP would crash LabVIEW).  Tech Support has been working on it for 3 months with no help (they see it too).

[rolfk]

LVLIBP!!!!! Where are they located in your environment? In your project tree or rather in user.lib or something similar? There is definitely something weird happening when using lvlibp’s that reference others over more than 2 hierarchy levels! The fact that the error indicates something amiss with the classes is most likely just a false flag and the real problem comes from the use of lvlibp’s!

[Ficare]

@Rolf

Interesting !

Which place would be the best for lvlibp ?

Phil