LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Broken packed project library (lvlibp)

Solved!
Go to solution

I have an interesting error with packed project libraries. Library (LV code) has nor errors at the beginning. When i build packed project library with "Disconnect type definitions" checked, library also has no errors. (When i don't check "Disconnect type definitions" packed library is broken btw). When i use packed library at a new project and inherit a new class from the (Functions Common) class inside the packed library, the library seems ok but when i try to compile to a new packed library app builder terminates with errors. Then i close and open that project with packed library i see the library is broken.

 

First picture is the library code before distribution. Everything seems ok.

 

2020-01-13_15-13-00.png

 

Second picture shows the packed library after distribution. Everything still seem ok.

 

2020-01-13_15-17-58.png

 

Third picture shows the problem when i use the packed library as a part of another project.

 

2020-01-13_15-20-15.png

 

 

0 Kudos
Message 1 of 9
(5,325 Views)

Hi Zafer,

Did you move the compiled PPL before you included it in the new project? If so, try to open/add it in a new project straight from the destination (output) of the build and let us know how it goes,

Cheers

Cris

 

0 Kudos
Message 2 of 9
(5,254 Views)

Hi thanks for reply but i didn't move the PPL from its original location. I keep each PPL at the same directory. When I use any PPL at a new project and build another one I exclude both packed libraries and shared libraries. I generally have some weird PPL errors. One of my VI is broken (inside the PPL) if I don't check "Disconnect type definitions" box. When I have no errors with "Disconnect type definitions" box checked same VIs are broken when I use this PPL at a new project.

 

Edit: I use G# classes with Delacor Modules and JKI State Machines inside the library.

0 Kudos
Message 3 of 9
(5,214 Views)
Solution
Accepted by topic author Zafer.Depe

After a few weeks deeper search, seems I found the solution. As you see from the picture below I changed scope of the folder that icludes custom event references (type definitions) from protected to public. Then I build the library and used it as a part of another project without any problem. So the VI is not broken anymore.

 

By the way while I was searching I made some tests. When I added an event structure tho the block diagram and added the protected scoped event rerence type definition to the front panel of this VI, this VI become broken after the build. When I remove event structure there was no error. Even I didn't connect user events to the event structure, the VI was broken when both protected scoped user event references and an event structure was placed to the VI. Also error shows up after the build only.

 

 

broken library.PNG

0 Kudos
Message 4 of 9
(5,001 Views)
Solution
Accepted by topic author Zafer.Depe

After a while i discovered that built in packed project libraries including XControls are main reason of that kind of problems when using this library (ppl) as a part of another project. Sometimes ppl is broken itself. Usually another class(es) or library(ies) is locked for editing when using ppls including XControls.

 

My conclusion is stay away from XControls. If you have to develop large projects with ppls you must stay away from them..

Message 5 of 9
(4,927 Views)

@Zafer.Depe wrote:

My conclusion is stay away from XControls. If you have to develop large projects with ppls you must stay away from them..


It seems the general concensus is to stay away from XControls, library or not. 🙂

Good you found a solution, a shame it had to come in such a harsch way.

/Y

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 9
(4,922 Views)

@Yamaeda wrote:


It seems the general concensus is to stay away from XControls, library or not. 🙂

 


It took one mounth to obtain this information 😄. Now I strongly recommend anyone to stay away from them 😂

Message 7 of 9
(4,918 Views)

There's been many threads about XControls. Too bad you didn't see e.g. this one: https://forums.ni.com/t5/LabVIEW/Packed-Library-PPL-Containing-Nested-XControls/m-p/4018536

/Y

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

Qestit Systems
Certified-LabVIEW-Developer
Message 8 of 9
(4,912 Views)

This post is newer than mine. My advice to him is not even attemp to do this. Just get rid of XControls. His demand has not a right way to fulfill.

Message 9 of 9
(4,910 Views)