Plugins without lvlibp, but with simple lvlib

[kosist90]

Dear NI Community,

let me ask you a noobie question.

Maybe you can say that I'm lazy to check it by myself, but let me ask the following - is it obligatory in case of plugin architecture with OOP approach to use packed libraries for generic class, and for plugins? 

Or, I still can use source distribution of ordinary lvlibs?

Because in case of plugins based on VI server architecture, no ppls are required - plugins are distributed as ordinary source distribution files.

Isn't it possible to do the same in case of classes? 

Because lvlibp - is nice to have, but there is all the time issues while migrating between different LabVIEW versions (what sometimes I must do, whether I like it or not), b/c rebuild is required. Plus - I can't save to previous version the whole project, b/c it refers to lvlibp, which can't be simply saved to previous version.

So I'm thinking to distribute OOP plugins as source distribution with my exe - but I'm not sure, whether it would work.

Did anyone implement it like this, or use of lvlibp is the only way to handle this topic?

Thank you very much in advance,

Sincerely, kosist90

[tyk007 · Accepted solution]

You can most certainly use just the original source files, as long as you do not separate compiled code (so that the files will be executable in whatever run-time engine you are using) or use a source distribution.

In my opinion the main reasons for PPL preference are the Single file and thus easier to distribute and the ability to version appropriately. Their other advantages (removal block diagrams etc.) could be managed via source distribution build spec as well.

[crossrulz]

With lvlib, you have all the VIs that are in the library and those it depends on freely running around.  If any are moved, the entire library is broken.  The PPL bundles everything nicely together in a single file.

And you still have to have the library saved in the right version for the RTE to use it.

[kosist90]

Thank you for your answers!

As per now, my main issue is working with plugins in edit-time - so if I'll be able to switch between LabVIEW versions more easily (like in case of "pure" source code), it will allow to create also builds in proper LV RTE much easier.

But yes, lvlibps are much easier to distribute - one file, no worries that somehow something would be missing...

Sincerely, kosist90

[SergioR]

Another downside developers interested in this topic should be aware of relates to class inheritance across packed libraries:

Suppose that ClassA is built into a lvlibp and distributed to the vi.lib folder. I create ClassB, set it to inherit from ..vi.lib\ClassA.lvlibp:ClassA.lvclass, and build ClassB into another lvlibp (I exclude dependencies, because ClassA.lvlibp is already in vi.lib, otherwise a second ClassA.lvlib is built). In this scenario, ClassB.lvlibp cannot be opened nor loaded into a project, unless ClassA.lvlibp is in memory first.

This also affects palettes. Suppose you ClassB is contained in a library, lvlib, with a custom palette mnu file included. This would allow dropping the built ClassB.lvlibp into a palette, and the palette will update with the contents of the mnu file. In this situation that ClassB.lvlibp cannot be loaded, it also cannot be added to the palette.

Removing the inheritance relation from ClassA->ClassB, rebuild the packed library, and then the lvlibp file can be loaded and placed in palettes without issues.

[LabVIEW 17.0f2 (64-bit)]

... hope someone can correct me about this... It has bugged me for days 🙂

Regards

[Johann78]

Hi Kosist90,

I had the same issues and questions the last 12 years.

We've tried a lot to setup a flexible, modern OOP Plugin model in Labview.

Source distribution makes problems (paths, no namesspaces working). and lvlib are terrible because project becomes slower and slower when dependencies are growing....

Subversion will become a nightmare, too (all files are changed, but they are not changed).

On that topic Labview support told me to "seperate source code and compiled code".

Nice , but then som strange errors appear sometimes "Could not load front panel" and in worst case it can't be opened anymore.

So we decided to create a class, put it into a packed library and inherit from it in the subclasses and put these packed libraries in one folder to load them dynamically.

But there are still issues: Interface between libraries? Queues, Notifiers? They don't work if Labview version is different!!! Compile all modules new? That's **bleep**.

Actor Framework? Never saw such an ugly solution - and terrible as packed library.

So at the end I recommend to do all stuff in C# and build Windows Forms dll (if you need a UI) or a simple OOP thing c# dll where inheritance and all is just there. No problem with namespaces, subversion,....

But then there is no reason for Labview anymore because there is still!!!! no GUI container or anything with a software developer needs!!!!

So finally Labview is maybe nice for prototyping for physics and children, but at the moment (I still hope maybe in future) no real software tool for modern , big projects.

Johann

[JÞB]

Are you really sure that you want to start a discussion about packed libraries vs libraries?

I am not going there! Get a specialist like AQ to help.