Packed Library (PPL) Containing Nested XControls

[Mr._Jim]

Hi Folks,

Before I begin, I have attached an example to illustrate what I'm asking about. (LV2019 64 bit)

I'm trying to create a single PPL containing two XControls. One of the XControls contains instances of the other XControl, and they both share a typedef.

What is the proper structure and workflow to create a packed library without painting myself into a corner?

Here's what I'm running into:

First Attempt:

If I create an lvlib, I have to do it outside of the project and directly from the lvlib so that Sub_XControl isn't locked due to it being loaded in TopLevel_XControl. No problem.

Next, while I have the lvlib open with Sub_XControl already in it, I add TopLevel_XControl. This results in the lvlib being locked such that no more modification can take place and it is paradoxically intertwined. (or insert a more colorful term there if you'd like) The only way I've found to get out of this situation is to revert from SCC or use VI Server to disconnect the XControls from the library.

Second Attempt:

For this scenario I compile Sub_XControl into its own PPL that also contains the shared typedef. I then create a separate project for TopLevel_XControl and link it to the compiled version of Sub_XControl, with the shared typedef living exclusively in Sub_XControl's PPL. What ends up happening is that when both XControls are compiled in their respective PPLs, code that calls TopLevel_XControl has a tough time resolving the linkage to the compiled SubXControl. If I carefully put compiled Sub_XControl into memory ahead of time, and then load TopLevel_XControl, I can sometimes get them both to load successfully. More often than not, though, TopLevel_XControl is broken due to an unresolved external dependency. If I tinker around enough it eventually links, but it's not reliable.

Has anyone been through this before? What is the right way to accomplish this?

It's rare that I use XControls, but we have some dynamically configured hardware that needs a user interface and this seems like the cleanest way to write that interface.

Thank you as usual,

Mr. Jim

[Mr._Jim]

For what it's worth, I also tried making a separate lvlib for Sub_XControl and nesting that lvlib within the one for TopLevel_XControl.

(per inspiration from an old post by Nancy that doesn't reference XControls) Then I compiled the top level lvlib into a PPL.

I still get a broken facade on TopLevel_XControl even when both XControls are baked into the same monolithic PPL. Maybe I'm not doing it right.

[TheQ]

I have been through some of the exact scenarios you have seen. What I ended up determining is that there is no way to do it right and have it be reliable.

This is the exact reason I created QControls. I have posted my detailed reasoning here on the LabVIEW Wiki.

Short answer is XControls don’t play nice with Libraries or Classes, especially PPLs; and I can’t imagine the level of complexity you get into with nested XControls. 

You can keep hitting your head against the wall here as I had done and you might find a way to get it working. That is until the next time. But I suggest using QControls instead. 

The QControl Toolkit is free on the Tools Network and there are lots of resources out there on how to use them. The best place to start is the QControl Enthusiasts page.

I hope this helps. 

[Mr._Jim]

Hey there Quentin,

Ah yes, QControls ring a bell from past CLA Summits. Given my infrequent use of XControls I sort of filed away QControls in the back of my mind as something I may need someday. Now might be that time, so I'll take a look at your work.

Thanks for your input! I'm glad I'm not the only one.

Mr. Jim

[Zafer.Depe]

I tried everything possible (independent ppls for each XControl, ppls containing XControls loaded from another ppl,...  ) but at one point project libraries or classes become locked or some ppls get broken, etc. Seems there is no way to use XControls properly. Just get away from XControls. Better NI should remove XControl support from Labview.

Broken packed project library (lvlibp) 

[nanocyte]

This is a long shot but does anyone have a CAR for this issue? I'm just curious if it's been fixed. I expect it has not been but if it has, it should save me a bit of time.

[DerrickB]

Are you aware of the Unlock for editing in the right-click menu of Xctls?

There are still some bugs and the xctls still show as locked in the project but I was able to edit the facade VIs (I think my labview install is borked, it was telling me I wasn't licensed to work with xctl file types)

Unlocking Top-Level First

Unlocking sub XControl

Editable Facade

So it still looks funky but it can perhaps let you make changes as needed. It wouldn't let me apply changes to instances on the top-level xcontrol when I was done though, I had to close and re-open the project but I didn't have to do any source control or file system shenanigans.

Another trick I've done in the past is to have separate projects for them where I close out of all projects using xcontrols and work on them in isolation.

[paul_cardinale]

I haven't used PPLs, but this kind of headache is what lead me to invent Y Controls (https://forums.ni.com/t5/LabVIEW/Y-Controls/td-p/4098200/page/4).

I still want to make a few changes to Y Controls:

1. There's a typo in the help
2. I want to improve some of the error messaging
3. I want to improve the templates
4. I'm having problems with a buildspec* in a giant project; don't know yet what's causing it, but it's possible that it's a bug somewhere in Y Controls.

* Saving VIs without BDs is breaking some of them.

[paul_cardinale]

[SlippinJimmy_]

As far as you know, are still there "compatibility issues" with XControls inside Packed libraries?

Thanks