PPL class context help

[SergioR]

Hello,

Working with source code, when the mouse hovers over a class wire, class control, etc., the context help window displays information about the private data cluster of the class. For descendant classes, it displays the descendant's details plus the ancestor's details.

When the class is built as a packed project library (PPL), the information regarding the class' private data is not visible in the context help window. Is there a recommended workaround for this? I am aware that private elements are not exported when PPLs are built, but I find it a big drawback for documentation purposes, that a PPL class is missing such information.

Thanks, 

[ikaiser]

Hello SergioR,

If I am not mis-understanding your question, you want to check Enable Debugging in Advanced in the Build Specifications of your PPL. A normal PPL does only contain compiled code, which lacks an accessible form of the information you want to see in the Context Help. With debugging enabled, your code itself is also stored in the PPLs, therefore allowing LabVIEW to display more information.

Just be aware that this makes the PPL files much bigger, and also allows to access the Block Diagrams in Debugging mode.

[SergioR]

Hi Ingo, tanks for the reply.

I had originally changed the Source File Settings not to remove the block diagrams from the PPL, but now I see that Enable Debugging does the same thing. Unfortunately, checking this box does not improve the information displayed in the Context Help window about my class.

This is the context help in the source code... I have a class inside a library:

This is the context help in as a packed library. The private data cluster information is not shown.

A bit of background... I would like to have block diagrams visible, debug enabled, full context help information and ability to probe class wires (see here), because the end-user of these packed libraries are developers, who may need to debug their own applications. I am trying with packed libraries to build my library of components as plug-ins, to be able to use these plug-ins in EXEs, and for the ease of single-file distribution.

Best regards,

[aptivo]

I had a closer look into my application. The class data is shown for the class itself, but not for class inside the ppl. Debubbing is as well activated...

[ikaiser]

SergioR, can you provide a minimal example of your exact setup here? Having a class in a library inside a PPL show its data type content in the context help is what I often use, so there must be some difference in what I do to what you do. Or I understand your description in a wrong way. Seeing it in code could give me a hint.

I am thinking of a project that contains a simple class and the build specification for your ppl.

[SergioR]

Hi Ingo,

Please find attached the example. It consists of a project with a class in a library. The build specification builds the library into a project library. The lvlibp is already built in the zip file. You should be able to re-built it yourself.

You may try, with the source project closed, to create a new VI and drop a method from the built lvlibp. Wire an object constant to its class terminal and hover the mouse over the wire. The context help only tells the Data type of wire, but it doesn't show any information about how the class private data is composed.

On the other hand, hovering the mouse over wires inside the source code, displays exactly how the class private data is composed in the context help.

Let me know if you find something. I appreciate your help.

Best regards,

[ikaiser]

Hello SergioR,

Thank you for your example code. I fear you are completely correct, and what I had on mind was mixed up.

I remembered a customer's Actor Framework + Plugin Structure project where I thought I had moved dependencies from "PPL" to "PPL with debugging enabled" and then the data type structures showed up in context help. However, my SVN proved me wrong: Actually what I did was partially moving from PPL to lvlib, and there (as expected) all private data types are shown.

I checked all project I recently worked on; all behave as in the screenshots you provided above.

Which makes sense, as keeping private data fully private was a design decision (described here: LabVIEW Object-Oriented Programming: The Decisions Behind the Design), and accessors are an easy way to provide defined access. I understand how displaying the inner data in Context Help would help. However, in my plugins private data often contains much more data than is accessible from outside - having this shown in Context Help would just clutter the help window.