Darren

Again, it all comes down to what framework(s) "click" for you. I personally would develop the application entirely with DQMH, here's a very introductory article on how DQMH and HAL concepts work together. Other developers would have great success sticking purely to Actor Framework. Still others with JKI SMO. Learn about the different frameworks, see which one(s) align the best with your mental model, and go in that direction. But whatever you do, don't create a new framework. P.S. - I wrote this article which might also be a good resource for you.

I worked on a project a while back that used JKI SMO for some lower-level functionality and had DQMH modules up top that used the JKI SMO classes. It's definitely possible, and desirable for some teams, depending on the skill level of the team members, their preferred frameworks, and which parts of the application they're responsible for.

Note: If you have trouble downloading the attachment above, it is also available on the NI forums here.

If you get a chance, please PM me the support case number for your interaction with NI Support.

It's because your indicator has the string as the last element in the cluster, not the first. If you change your Bundle function to have the string as the 3rd element wired in instead of the 1st, the wiring will work. I suggest you review the topic of Type Definitions in LabVIEW, where you can define a data type like a cluster in a single location, and use that type definition in all places in your code where you need that type. It helps you avoid situations like the one you describe.

This utility VI is helpful for filtering out only contained controls in a right-click Affected Items array. [LabVIEW 20xx]\resource\plugins\PopupMenus\support\Filter For Contained Controls Only.vi Many of the shipping right-click plugins use this VI for the exact purpose you describe... for example, check out the source code for the Change To Array Or Element plugin: [LabVIEW 20xx]\resource\plugins\PopupMenus\edit time panel and diagram\Change To Array Or Element.llb\Change To Array Or Element.vi

Relevant slide from my Don't Wait for LabVIEW R&D... Implement Your Own LabVIEW Features! presentation:

I assumed he was referring to non-VIPM dependencies, like NI installers which, to my knowledge, VIPM doesn't check for. But you're right, he could look for the dependencies in his pre-install VI. But maybe his package is still useful even if those dependencies aren't installed?

Can you use the private UnattendedMode property in your post-install VI? The searches would still take place, but at least you wouldn't have to see the dialogs? Could you replace the calls to possibly-missing VIs in your code with dynamic calls? This would work if there were only a few calls.

For a regular library (.lvlib), opening a reference to it (via the 'Library.Open' method) will not bring member VIs into memory. For a class (.lvclass), opening a reference to it (via the Library.Open method) will bring all member VIs into memory. There's no way around this behavior that I know of.

It calls a private internal method, yeah. NI policy is that VIs that call private properties/methods/events are password-protected.

There's also the Create NI GUID.vi in LabVIEW 2020 and later.

For DQMH, the term "singleton" means that the Main VI of the module is non-reentrant. A "cloneable" module has a reentrant Main VI. So if you have a reentrant instance running (of Power and IG), then that instance will also need its own associated reentrant instance of PS class.

From your description it sounds like the PS Class module has to be cloneable. Otherwise all Power and IG instances would be sharing the same singleton instance of PS Class, which I'm guessing is not what you're going for.

Individual apps have to include long path support in order for this setting to have any effect. And LabVIEW 20xx currently has not added this support. Please kudo this idea (if you haven't already) to increase the visibility of the feature request with LabVIEW R&D.