How to export code for end users that is cleaned

[MaSta]

Why: for later linking the LVLIBP in the context menu

You can edit all palettes and then the MNU is changed and you can pass the MNU to someone else. The alternative is to create a custom MNU for every subfolder. Normally not needed this is the way to go for distributed packages, as I learned. 

[wiebe@CARYA]

---

@MaSta wrote:

@wiebe@CARYA: I had to restart LabVIEW, then the (app) builder would start again.  

By the way, I had never tried the export method "Source Distribution", but if I use the option to remove the block diagram, the build fails on a LV class sub vi.

---

I guess source distributions didn't get much TLC after classes where introduced.

It does (theoretically) sound like what you want ("export cleaned code for end users"), but I had a feeling it would fall short.

If what you really want is to provide a usable library (not source), I'd go PPL.

I would use PPL, if only they'd run on 32\64\RT*  and if there was a way to include .vim's.

*Not just the target they're compile for. I could live with that if I could cross compile for all targets from one host.

[MaSta]

PPL = packed project library? That is the LVLIBP I'm talking about all the time. Creating it is cumbersome.

[GerdW]

Hi MaSta,

---

@MaSta wrote:

That is the LVLIBP I'm talking about all the time. Creating it is cumbersome.

---

Nope, creating a lvlibp from a lvlib is easy. (We use lvlibp's a lot since we also use TestStand a lot.)

It gets "cumbersome" when you want to solve issues lvlibp's aren't made for, like including your mnu file…

The purpose of a lvlibp is to provide a "blob" of related functions with a defined API.

It's not their purpose to configure the LabVIEW IDE to show some palette menus…

[MaSta]

@GerdW: wait, wait, wait...

The palette editor offers you to link a subpalette to an MNU file in a project lib, so it seems to me this is the intended way.

• I made a new project, added files and folder. In a 1st attempt, there was only one palette file (dir.mnu) in the LIB. That compiles nicely into a LIBP, but after that you get the above mentioned error loop with "dir.mnu". 
• So I thought the solution would be to use a palette file with different name and in every subfolder. These add nicely to the LIB, but when there is more than one MNU file in the LIB, the builder to create a build spec for LIBP wouldn't start. Restarted LV a few times - no chance. So I RARed the LIB, removed the additional MNUs from the LIB, saved it, then created the build spec and unrared the previous LIB with the multiple MNU. It would compile into a LIBP.
• The result is but the same. That loop error with dir.mnu. Maybe, the reason actually IS the name of the dir.mnu. So I renamed the dir.mnu in my source path, replaced it in the LIB, compiled the LIBP again. No loop error anymore, one problem solved. 
• As a result, my LV would crash after a few seconds every time I opened the LIBP for use, like just look into it or drag a VI out of it. At this moment you can't be sure what's causing this, so I ran another attempt: removed all the MNU files from the LIB, compiled again. This LIBP wouldn't crash LabVIEW anymore. Doh!
• OK, my best guess was "maybe, the LIBP must only have 1 palette file and it must not be named dir.mnu". OK, compiled a third time. 
• Then I wanted to add the LIBP with the one palette file in it as source for the context menu, so I edited the LV palette, selected the packed lib and guess what - LV crashed again.
• Restarted, loaded the packed lib once more and it wouldn't crash just by using it, but the crash would still occur when editing the LV palette. 

I thought it's because LV tries to load some information from the MNU which, when being in the LIBP, isn't pointing to the correct path, because the LIBP might be in a build path. So it would have to be moved to the same folder first in which the MNU was created. Did that, edited LV palette, saved, new VI, context menu - boom! Crash. I need to find a tutorial about how to bring a palette file into a packed lib. 

[wiebe@CARYA]

Most people probably put the ppl in their projects, not in vi.lib.

So you might be on your own when it comes to the menus.

[MaSta]

I don't think so. People are used to open driver VIs from the context menu. Of course, that would it make easier for me just to hand them an *.lvlibp file.

[GerdW]

Hi MaSta,

---

@MaSta wrote:

People are used to open driver VIs from the context menu.

---

I don't place driver VIs from the palettes. I (mostly) never install them into vi.lib/instr.lib.

Once you put the lvlib(p) into the project you always have access to all needed VIs…

[JÞB]

---

@GerdW wrote:

Hi MaSta,

---

@MaSta wrote:

People are used to open driver VIs from the context menu.

---

I don't place driver VIs from the palettes. I (mostly) never install them into vi.lib/instr.lib.

Once you put the lvlib(p) into the project you always have access to all needed VIs…

---

Compiled Code does not belong in the IDE.  Lvlibp files are compiled and may be used as dependencies of any lvproj but, including an mnu file in the compiled package isn't the right idea.  The RTE cannot be used to develop code in the IDE.  You can drop public or friendly members of your ppl easily enough though.

To get your reuse code into Instr.lib vi.lib, projects or user.lib you need to supply source code (as lvlibs) but, now you need to either:

• Clean up the code to a code reviewed standard
• Hide all the ugly under the rug.  

NI sometimes chooses option 2

[MaSta]

I'll consider that. Thanks all. 

By the way, I figured it out. I can use multiple MNUs inside a packed lib. 😥