packed library bug

[User002]

I think there might be a bug/limitation when using packed libraries with classes inheriting?

In my example code "Class 2.lvclass" inherits from "Class 1.lvclass". See the project explorer and packed library explorer screenshot below:

The issue seem to be that only the overridden method "OverrideMethod.vi" seem to be included in the packed library? Shouldn't the super class static method "StaticMethod.vi" be included as well?

Regards,

/Roger

[gmart]

Packed libraries are used to define a set of exported VIs. These VIs are the only VIs that are visible in both the file dialog and the project. Dependencies are included in the packed library but are hidden. In your example, the static VI is in the packed library but not visible since Class 1.lvclass was not part of the source library but a dependency.

Another issue to consider is that once Class 2 Library.lvlib is built into a packed library, all files have a new namespace. The packed Class 2.lvclass will then be different than the source Class 2. This essentially cuts off the inheritance from source Class 1. If you want to retain the inheritance to a packed Class 1, you should make Class 1 be part of the source lvlib.

[User002]

Hello Geroge,

I am sure you are aware that this limits the usability of a packed library with classes since it is impossible to access the super class method by any reasonable means?

For example using your "solution" by including Class 1 and Class 2 to the same library, then I will have a dependency towards Class 2, even if I only intends on inheriting from Class 1 (and of course it's super classes), due to the nature of libraries?

To me that seems like a serious specification or implementation flaw, if not a bug?

Can we agree on that? 

Br,

/Roger

[gmart]

I think I understand what you want to do - have a parent class and a child class relation and then pack the child class and then be able to use the packed child class with the source parent's object. Is that correct?

Packed libraries are tools. As such, they may not be the right fit for all jobs. A feature of packed libraries is that all dependencies of the public items in the source lvlib are included in the packed library and get a new namespace. This isolates the built code from the source code. For that reason, you are seeing the issue I mentioned where the source and built code cannot have inheritance. This is no different than if you had dynamic call to a VI that was in one library and you added the VI to a new library. The namespace would change and thus the name used in Open VI Reference (for example) would need to be updated.

If you want access to parent classes in a packed library, then you need to include those classes in the source lvlib. This is the nature of the tool.

[User002]

Hi again,

What I want to do is simply to access the parent's class methods in the packed library, exactly the same way as I can do in a normal library?

But to do that in a packed library seems impossible due to "complicated namespace stuff"? (cough, cough, bug!) 

I already concluded that packed libraries is not the 'right tool for the job', therefore I started this thread.

Br,

/Roger

[gmart]

Another feature of packed libraries aside from namespacing is the ability to define an interface based on the scoping of items in the source library. Only items defined with public scoping will be accessible. All other files (including dependencies - Class 1), will be treated as private and thus not accessible. This is not a bug. This is desired functionality when defining an interface. Thus, the recommendation that if you want to access the parent class, make it a member of the source library and not a dependency.

[User002]

Are you serious in wanting all classes inheriting from a common base class to be placed in the library together with the class intended to be a packed library? 

[User002]

I do understand that coding to traverse the inheritance dependency tree is much harder than making all parent classes invisible, in order to determine the scope and visibility of the classes(and methods) when creating the packed library?

Is this the crux?

/Roger

[gmart]

I didn't quite understand your last post. The visiblity of the classes does not have anything to do with the inheritance. It is solely determined by the scoping defined by the source library. Public items isn the sourece library are visible Exported VIs in the packed library. Everything else is private and thus not visible.

[SteveChandler]

---

rois wrote:

I already concluded that packed libraries is not the 'right tool for the job', therefore I started this thread.

 

/Roger

---

It is not a bug though because it is doing what it was designed for. What you need is a different tool - you need a Bundled Project Library. It has all the features of a Packed Project Library without the limitations (cannot run on a different architecture without rebuilding among other things). It is like an llb in that it is one file that contains all the VIs with their source code. llbs do not give you namespacing and you cannot have two VIs with the same name ruling out dynamic dispatch. Bundled Project Libraries do allow this.

Unfortunately there is no such thing as a "Bundled Project Library" but you can help change that.