Palette frustrations

[Daklu]

I've rarely taken the time to create palettes for reusable code modules. I find it to be a royal pain in the arse and often the only thing I have to show for it is a headache. Call me crazy, but I decided to give it a go again. (Sure enough... now I have a headache.) I'm trying to figure out how to create palettes for my modules without duplicating the whole distribution directory structure in my dev folder or going through the hassle of NI's suggested method for creating palettes. I have a basic text-based mnu file editor I created last year that I've used with some success, but the rules of palette behavior still mystify me.

For example, does the .mnu file record absolute paths to the palette items or relative paths? The api help says you can use either with WritePalette; it doesn't say what format it is saved in. Sometimes it seems to be absolute, sometimes it seems to be relative. Some of the tests I've run imply the root project folder is used. Throw symbolic paths in the mix and the number of permutations needed to figure it out starts to get too big. Hitting the mnu file with a hex editor didn't reveal anything useful.

Anyone know if there's documentation explaining the mnu file rules?

[Ton Plomp]

In general LabVIEW paths will be stored relative, even if the target file resides on another drive (Windows only), you can see this in a lvprojectfile with a lot of ..\..\..\..\

On the other hand if the target file is inside instr.lib, user.lib or vi.lib an absolute path will be stored.

One thing to try is to create an mnu file the old hard way (edit palettes) and look into the actual created mnu file with an hex editor.

Ton

[Daklu]

Thanks Ton. That helped point me in the right direction. I've posted additional questions over on the Add-On Dev Center.