PPL Loading order - bizarre behavior

[CoastalMaineBird]

LV2018 SP1.

Between Labview's hiding information from me (" a subVI is missing from a packed library" is NOT A HELPFUL MESSAGE !) and its out-and-out lies, it's been a long slog to find a crashing problem.

I've boiled it down to something I can't explain.

I have a series of PPLs containing classes. The lowest levels are going to be dynamically loaded, and sometimes that process crashes ("We apologize for the inconvenience"), sometimes it crashes and disappears without a word, and sometimes it works.

If I breakpoint the dynamically-loaded class after it has been inserted into a subPanel, it works fine. If I don't breakpoint it, it crashes.

Here is the class organization:

PRINTOUT - a base class in PRINTOUT.lvlibp

DFV MODULE - a base class in DFV MODULE.lvlibp

DFV PRINTOUT - a child of PRINTOUT, in DFV MODULE.lvlibp

DFV MODULE for SINGLE TEST - a child of DFV MODULE, in DFV MODULE for SINGLE TEST.lvlibp

DFV PRINTOUT for SINGLE TEST - a child of DFV PRINTOUT, in DFV MODULE FOR SINGLE TEST.lvlibp

DFV MODULE FOR TORQUE MAP - a child of DFV MODULE for SINGLE TEST, in DFV MODULE for TORQUE MAP.lvlibp

DFV PRINTOUT for TORQUE MAP - a child of DFV PRINTOUT for SINGLE TEST, in DFV MODULE for TORQUE MAP.lvlibp.

The MODULEs and PRINTOUTs are not related to each other(ancestrally) but are co-dependent, because I need to transfer info from one to the other at PRINT time.  They are therefore in the same LVLIB and this in the same LVLIBP.

I've boiled it down to this ScreenCast.

All PPLs are built.  I'm starting without a project, on a new VI.

0:10 Place the youngest MODULE on the diagram.   OK

0:17 Place the youngest PRINTOUT.  - OK

0:33 Place the parent MODULE  - OK

0:42 Place the parent PRINTOUT  - IT'S MISSING ? ? ? How can it be missing when I just placed it there?

0:58 Place the grandparent MODULE - OK

1:08 Place the grandparent PRINTOUT - OK.

1:20 Place the G-grandparent PRINTOUT - OK.

So, how is a class missing when I found it and placed it there ?

1:36 Place another parent PRINTOUT - it's still missing.

"This constant refers to a class that is missing" seems like a lie to me.

1:49 Erase all items and start over from the other end of the ancestry chain.

2:00 Place the G-grandparent PRINTOUT - OK

2:12 Place the grandparent MODULE - OK

2:26 Place the grandparent PRINTOUT - OK

2:36 Place the parent MODULE - OK

2:45 Place the parent MODULE - FAIL - IT'S STILL MISSING ? ? ?

2:56 Close the whole VI and start from the oldest end of the ancestry chain.

3:13 Place the G-grandparent PRINTOUT - OK

3:23 Place the grandparent MODULE - OK

3:31 Place the grandparent PRINTOUT - OK

3:41 Place the parent MODULE - OK

3:54 Place the parent MODULE - OK !!!  If you look closely, you can see the icon flashing between the white "missing" one, and the real one, but it ends up with the real one.

4:08 Place the MODULE - OK.

4:18 Place the PRINTOUT. - OK.  This one also flashes white.

I have verified that the ancestral chain is as expected and as stated above. 

If I save this VI, with all classes intact, I can load it again and the same one is now missing.

If I reverse the order of classes when building the SINGLE TEST ppl, it's the other class that is now "missing"

I have proven that it is legal to have two classes in one PPL - the DFV MODULE does that without issue.

Anybody have any insights ?

[CoastalMaineBird]

I tried making the PRINTOUT class a "Friend" of the MODULE class, and vice versa.  No change.

[CoastalMaineBird]

More cases of info hiding and plain untruths LV is telling me...

By eliminating all the PPLs from my project, and then inserting the G-grandparent, Grandparent, and parent PPLs IN THAT ORDER, I was able to keep the main program from complaining about a missing class.  IOW, instances of those classes survived closure and reopening of the project.

The same is NOT true of the low level PPL however.  I did remove PPL inclusion and then included  the G-grandparent, Grandparent, and parent PPLs IN THAT ORDER, and placed an instance of each on the diagram.

However it returned to a previous malfunction - feigning ignorance about class compatibility.

It complains about a subVI missing from a PPL, but it won't tell me which subVI or which PPL.  It thinks there's a class missing, but it's right there.

A lot of the other errors are a result of that.

Here's where the lie comes in:  The VI WILL BUILD JUST FINE.  If all those things are broken, it shouldn't let me build it, but it does.

To prove I'm building what I think I am, I put an INCREMENT function on the diagram and built again,  This time the build breaks, as it should. Remove that INCREMENT, and it builds again, despite it being "broken".

Arrghh.

SCREENCAST 

[CoastalMaineBird]

More info:

Loading the project shows the error.

0:00 Open the project and the VI.

0:08 The VI loads broken.  The CLASS is wrong, the CLASS is missing.

0:20 Close the VI and the project.

0:29  Open the ancestor PPL manually (from dialog). LEAVE IT SITTING OPEN.

0:40  Open the project again.  Open the VI again

0:46 IT OPENS UNBROKEN !.

0:58 Unsaved Changes indicates that something was modified.  WHY IS IT NOT TELLING ME EXACTLY WHAT ?

If I save the changes from this "fixed" state, the next load is still broken.

SCREENCAST 

[CoastalMaineBird]

Boiling it down even further:

There's nothing in the PROJECT file except the two classes in one PPL

The USER INTERFACE VI that I open is a method of DEF MODULE for TQMAP,

which is a child of DFV MODULE for SINGLE TEST.lvlibp: DFV MODULE for SINGLE TEST,

which is a child of DFV MODULE.lvlibp: DFV MODULE.lvclass

Here I'm calling the base class UI START and UI STOP, from the DFV MODULE.lvclass

SCREENCAST 

0:00 The VI is NOT BROKEN. The ppl DFV MODULE for SINGLE TEST is open nearby.

0:06 I SAVE the VI, just to show that I've saved the good condition.

0:14 I CLOSE the VI, the project and the ppl.

0:25 I OPEN the project and the VI, and guess what - IT'S BROKEN!

0:30 The diagram shows a class conflict between the terminals and the vi being called.

0:33 The Error list complains of a class conflict because "there's neither a simple up cast nor type case between the two classes"

 In spite of the fact they are direct descendants!

0:54 Closing the VI tells me that it has been recompiled. LabVIEW hides the reason why.

1:00 Close the VI and project

1:08 Open the PPL and set it aside.

1:22 Open the project and the VI and NOW IT'S UNBROKEN !

1:35 Close the VI and it does NOT need to save changes.

I didn't show it but the DFV MODULE for SINGLE TEST is in the folder labelled PPLs in the project.  

The diagram includes instances of classes from that library.

You'd think that was enough.

What is going on?

[CoastalMaineBird]

OK, last shot for today.

I cleaned all the cruft out and did a master rebuild (about 20 projects). Everything went fine.  The final products worked OK.

BUT STILL.

I go back to the problem project, and it shows up broken.

But get this- When I load it, it shows up broken.  If I try to CLOSE it, it tells me that things were changed on the diagram.

I DIDN'T CHANGE ANYTHING.  

If I do NOT close it, but instead REVERT - it heals itself.  If I close it NOW, it doesn't warn about changes, it just closes.

If I close the project and open again, it starts over as broken.  REVERT fixes it.

SCREENCAST 

[CoastalMaineBird]

Is there a rule about inheritance that I don't know about ?

OK- brand new project (from scratch), brand new library, brand new child class.

Green is the new class, which inherits from Purple (which is compiled into a PPL), which inherits from Yellow (which is compiled into a PPL), which inherits from LV.

The Green class implements a method, which calls a YELLOW vi.  Same misbehavior:

--- it complains about a class mismatch between the class input terminal and the ancestor method) when it's first loaded.

--- a CLOSE will ask whether to save changes (I didn't make any).

--- A REVERT corrects the mismatch and "heals" it.

--- Now a CLOSE will NOT ask about changes.

--- If I open the purple PPL and leave it sitting open when I open the project, the VI shows up correctly.

--- If I close the purple PPL, close the project, and then open the project, it goes back to step 1 (broken).

QUESTION:  Is there some rule about not inheriting through TWO PPLs?  If I change the green class to inherit not from the PPL (LVLIBP) version of the purple class, but from the source (LVLIB) version, there is no error.

I don't want to do that, because it exposes the source code of the purple class(my code) to the writer of the green class( my customer), but the fact that it works that way might be a clue.

Then again, it might not.

[CoastalMaineBird]

Is there a rule about inheritance that I don't know about ?

No, that can't be it. I have another case from the same ancestry.

Instead of DFV Module --> DFV Module for Single Test ---> DFV Module for Torque Map

there is DFV Module --> DFV Module for Graphs --> DFV Module for XY Graph

There are four children at that last level, everything is built into PPLs and they all work fine.

[CoastalMaineBird]

OK, maybe I've figured it out.  Before I put that in writing, notice this little beauty:

This new error has appeared. 

SCREENCAST 

0:00 Notice the VI is broken - the TEST FACTS property is not valid. At least, LV is TELLING me it's not valid. It's a lie.

0:06 Place an unwired INCREMENT on the diagram and then BUILD the PPL.

0:10 It will not build because the VI is broken.  No surprise.

0:15 Delete the INCREMENT.  Notice that IT'S STILL BROKEN.  At least, LV  is TELLING me it's broken.  It's a lie.

0:20 Build again.  IT BUILDS. Despite it showing as broken, it will still build. Without error.  and then crash when run.

[CoastalMaineBird]

Well, it's not 100%, but I figured out the problem causing the above scenario.

The property was called "Test Facts"

The MODULE class had a property called "Test Facts" with only a READ component.

The PRINTOUT class had a property called "Test Facts" with only a WRITE component.

The fix was to change the name of one of the properties, so they don't match.

It looks like:

IF 

    Class 1 and Class 2 are in same library

AND

    Class 1 has a property named X

AND

    Class 2 has a property with the exact same name

THEN

   LV will get confused about which property belongs to which class and complain to the user, while the compiler will compile something anyway.

Now, everything compiles 100% OK and works 100% OK, AS LONG AS DEBUGGING IS ENABLED FOR ALL PROJECTS.

If I disable debugging, it compiles 100% OK, and none of the mystery errors above show up, but I get an error 1498 when some (not all) of the child classes are dynamically loaded.

And of course, LV hides information that would lead me to find the problem.

"library has errors" indeed.