10-24-2025 02:31 PM
I'm trying to write a VI that will just add a subpalette to the Programming menu
I have attempted to implement it like this:
But it doesn't work. The new subpalette will show up in "items" after repeated runs, but I can't get it to appear in the palette except by manually editing via "Edit Palette Set...". I've tried a bunch of combos of restarting LabVIEW and adding/deleting manually but now I'm stumped. What's troubling is I have previously had a VI that did this exact thing but I have lost access to it so I don't remember if there is some trick I'm missing here.
Running 2023Q3 32-bit, Windows. This VI can't be backsaved before 2023 due to the resolve path node on the left. Thanks for any pointers...
Solved! Go to Solution.
10-24-2025 06:40 PM
I've not tried this myself but I do notice that the palette edit functions have inputs for an Application reference, as well as the "Refresh palette" invoke node.
Maybe if you create a "This Application" reference and pass it in to all of them? I've seen weird scripting interactions before that don't work without an Application reference passed in to be sure everything is operating in the same application space.
10-27-2025 05:02 PM
@Kyle97330 wrote:
I've not tried this myself but I do notice that the palette edit functions have inputs for an Application reference, as well as the "Refresh palette" invoke node.
Maybe if you create a "This Application" reference and pass it in to all of them? I've seen weird scripting interactions before that don't work without an Application reference passed in to be sure everything is operating in the same application space.
No change like this, also realize I forgot to post code.
10-27-2025 05:37 PM
I can't try it at the moment myself, but any chance there's something missing from the Items entry?
If you manually add it, then read "Items", how does it compare to the Items element you're manually bundling?
Are you certain the path is correct? The help says it won't add an item if the path is incorrect.
10-29-2025 01:02 PM - edited 10-29-2025 01:54 PM
The issue was that manual edits were going to "Documents\LabVIEW Data\2023(32-bit)\Palettes\menus\Categories\Programming\dir.mnu" and this mnu was the one actually used to populate my palette, but my programmatic edits were going to "C:\Program Files (x86)\National Instruments\LabVIEW 2023\menus\Categories\Programming\dir.mnu".
I believe what happened is when I started working on this the mnu in program files was being edited and at some point, probably when I started doing manual edits, the one in documents was created and started being used. I checked a colleague's computer and they don't have the one in documents. This is very annoying from my perspective because now I need to handle both cases. I'm not sure if older LabVIEWs had this behavior.
10-29-2025 01:59 PM
I don't have one in the My Documents folder (LV 2023, 64-bit) for what it's worth.
I found some info on your new file's location based on this old article: https://forums.ni.com/t5/Developer-Center-Resources/Creating-a-LabVIEW-Palette/ta-p/3520557
It looks like the directory you're looking at is for user-modified menu files. Luckily there is a "Default data directory" primitive that'll return the location of this, and not have to worry about hard-coded filepaths.
I haven't been able to figure out how it handles a .mnu file in both locations... it doesn't seem particularly well documented.
One thing to mention is that VIPM has a solid built-in palette feature, so if you're making your own installable library it might handle some of this for you. At the very least, you should be able to get symbolic paths to everything you're looking for.