Darren

The 'Arrange VI Window' Quick Drop keyboard shortcut does this. With the diagram open, Press Ctrl-Space, then once Quick Drop appears, press Ctrl-F. If you want to look at the code that accomplishes this, see here... it should be a good resource for writing your own tool: [LabVIEW 20xx]\resource\dialog\QuickDrop\plugins\_Arrange VIWin SubVIs\Arrange VIWin - Arrange BD.vi

The multiple patterns nugget was broken in LabVIEW 2023 Q1, but it works in LabVIEW 2023 Q3 and later.

The App Builder API is not supported within a built EXE. It can only run in the LabVIEW editor. More generally, there is no way to build a LabVIEW EXE that can build LabVIEW EXEs.

There is an App Builder API which will allow you to accomplish this task, but it is not officially supported by NI. The VIs are in [LabVIEW 20xx]\vi.lib\AppBuilder\AB_API, and there is an examples subfolder there with a few examples that should help you get started.

There have been a couple of patches released for LV 2023 Q3 that you can install from NIPM that fix (among other things) some App Builder issues. If y'all install those patches and still see issues, I know that LV 2024 Q1 is releasing shortly, which also includes some App Builder fixes. Additionally, if y'all are able to share code, feel free to PM me and I can get Bugs filed to R&D for build issues that we can reproduce in-house.

If your cluster contains elements that are all the same data type, you can use the Cluster To Array function. If your cluster contains elements that are different data types, then the approach you describe won't really work due to LabVIEW's strict data typing.

What is your use case for needing this behavior?

I believe this has been reported to LV R&D as Bug 2561077. It is scheduled to be fixed in the LabVIEW 2024 Q1 release, and they are also researching whether or not to include the fix in a patch to LabVIEW 2023 Q3.

If you're still having issues, and you're able to share the VI with me, let me know... I can take a look.

(Disclaimer: I am not an NI insider, and I have no inside knowledge of the pending Emerson acquisition) I think we're all sort of in a holding pattern waiting to see how the Emerson acquisition plays out. Emerson's outward messaging seems very positive towards LabVIEW, which I find encouraging.

I like remixicon.com. Everything there is free for personal or commercial use. Here's what they have for a search term of "door":

Antoine is correct, those diagrams should function identically.

The issue was reported to LV R&D as Bug 2317159. It was introduced in LabVIEW 2022 Q3 and fixed in LabVIEW 2023 Q3. The Error 13 occurs when the LabVIEW Class private data includes certain types of .NET references, or a reference to a .chm help file. More details: LabVIEW 2022 Q3 included a "fix" to how linkages to .NET assemblies are adjusted in a build output. Unfortunately this "fix" caused the issue you're seeing. LabVIEW 2023 Q3 uses a new mechanism for app builder caching under the hood, which removed the codepath that was causing the Error 13 altogether.

I think this issue may have been fixed in LabVIEW 2023 Q3. Are you able to upgrade and try it out?

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.