Malleable VIs in Packed Project Libraries

[hbaron93]

Hi everybody,

I'm starting to get around with Packed Project Libraries, and I've just tried to build a PPL containing a LV Class which had (among other normal VIs) two malleable VIs as public methods. For some reason, the VIMs don't get included in the packed libary. Is that an expected behavior?

Thanks!

Best Regards,

Henrique Baron

[crossrulz · Accepted solution]

---

hbaron93 wrote: Is that an expected behavior?

---

I would say so.  Malleable VIs are more like templates for inlined code.  They are not compiled at the vim level.  So it makes sense that they should not be included in a compiled library (PPL).

[hbaron93]

Thanks for the answer crossrulz. The malleable VI I was using actually had as input an object of the class that I compiled in the PPL. The problem is that the class namespace when using the project library changes and the malleable VI becomes incompatible (because of class conflict) with all the other methods that were included in the packed library.

Guess I'll have to look for a workaround to replace the VIM and keep with the packed library.

[Mads]

How did you manage to make the "two malleable VIs as public methods" in the first place?

I wanted to make that, but as soon as the method is saved as a VIM it breaks, and I assume it is because of the inlining requirement combined with accessing the object, as the inlining then puts code accessing private data into a VI (the caller) that is not part of the class...(?). In other words public methods and VIMS are incompatible concepts due to the inlining requirement, or?

I have been searching for notices about this in the documentation, but have not found any yet.

[hbaron93]

---

@Mads

I wanted to make that, but as soon as the method is saved as a VIM it breaks, and I assume it is because of the inlining requirement combined with accessing the object, as the inlining then puts code accessing private data into a VI (the caller) that is not part of the class...(?). In other words public methods and VIMS are incompatible concepts due to the inlining requirement, or?

---

That's actually not true. Malleable VIs cannot bundle/unbundle a class data cluster, but they can call the private methods from the class they belong. So for the places of the VIM block diagram where you would need to bundle or unbundle the class data, you could create a private accessor method and it will work fine.

I've just tested it and the messages in the error list window are an intuitive guindance on that 

[Mads]

Ah, good tip. I would want the accessor in this case to be private, and did not expect that to be doable due to the inlining for the same reasons as not allowing the direct access to private data...but if that works then that's the solution 

[Mads]

There is some special magic going on here.....I can call an accessor in the Malleable VI even though that accessor is private, but if I try to call a private Method (VI), the malleable VI does not complain (not broken) - but it will then no longer accept any inputs at all(!).

Any inputs wired to the (public) class VIM will report that an unsupported data type has been wired to the malleable VI. This effect disappears as soon as the methodthe VIM is calling is made public. So private accessors are OK, but not private VIs 

[Intaris]

Are your other private VIs inlined? I think accessors are inlined by default.

I don't see why this should have anything to do with making them public fixing things.....

I mean private accessors and private VIs are essentially the same thing, right?

[hbaron93]

---

@Mads

---

Mads,

Can you send a minimal working example of your problem? I have created a project (attached here) which includes a class that contains a private method (not inlined, from static dispatch template) and private accessors for its data. A malleable VI calls both the method and the write accessor.

I am able to call the VIM from a VI outside the class with no problem in the example.

• Is there any possibility that you're wiring an incompatible type to the variant input?
• Do you have more than one variant input in your VIM? 
• Are you calling dynamic dispatch methods in the VIM (not sure this is a problem, but I haven't tested it in my example)?

[Mads]

Working on it...I quickly made a test set here, and it works too. So there must be something more complex going on in my original code.