Search the Community
Showing results for tags 'ppls'.
-
Inspired by my question from this post: link, I started off on a path of packaging project dependencies into vi.lib as suggested by @smithd and @Darren however I have started down a rabbit hole of packed project library (ppl, *.lvlibp) head scratchers that have left me a little confused on what is going on in the background. Most of my components are built into packed libraries because I am following plugin models for extensibility when building as an EXE. To make packed libraries work with dependencies, you basically have to build those into packed libraries as well to avoid the namespace issues. I used VIPM to create packages to distribute some of this shared code to vi.lib. In the example below, I created a packed library (Controls.lvlibp) and packaged it to vi.lib for use. In the Limits project in the image, I am using the Controls library in a few of the functions. Limits also contains a build specification to create a packed library for a component. However, I first noticed an issue when I looked at my child class projects (that inherit from the Limits.lvlibp:Limits.lvclass). The Limits.lvlibp is showing as Not Loaded. When I go directly to the library on disk and try to open it, I get the message "Project or Library file cannot be opened." I notice that if I get the correct Controls.lvlibp into memory by opening it up or by putting one of its VIs on a block diagram, then the library will load correctly. So, I know it has something to do with when data from vi.lib is loaded into memory, but I don't know how to force it into memory to get this to work correctly. Generally I am selecting the option to "Exclude dependent packed libraries" in my build specifications, but if I leave that unchecked it will open properly (because it places the dependency directly next to where it is built). I did not have these issues until I placed my shared components into vi.lib, so I would be grateful for any help to help me debug this!
-
The QControl Toolkit by Q Software Innovations is an object-oriented and extensible alternative to XControls. Use the QControl Toolkit framework and the QControl Creation Wizard to create QControl Classes and receive the benefits of XControls without the headaches. Take advantage of easy UI logic code reuse. Encapsulate and decouple the UI logic away from the business logic of the main application and from the UI skin. Use wherever the VI Server and LabVIEW object-oriented programming are allowed. Easily extend the capabilities of current LabVIEW controls through access to all properties available at run time. And easily use the toolkit with more complex frameworks like the Actor Framework or other plugin architectures where LabVIEW libraries and packed project libraries are used and where XControls can behave unpredictably. Check it out now on the NI Tools Network here. I also started a thread on the NI Community: UI Interest Group page, here.