Can't remove Front Panels in Application Builder

[m3nth]

I have had a few issues using Application Builder (v7.1) in regards to it removing or not removing front panels for my subvi's when I was trying to compile. Here are the conclusions I came to if anyone else runs into the problems I had.

Problem 1) Some of the front panels were being removed for dynamically loaded VI's, which were not set as dynamic VI's in the Application Builder, but which were static-linked VI's in the program (so they were loaded in memory as linked subvi's but called dynamically). When the Application Builder decided to remove the front panel for those VI's, there was an error when loading them dynamically.

Problem 2) Some of the front panels were NOT being removed for subvi's that I didn't want to have their front panel built into the compiled program. Loading front panels that are not needed uses extra memory, but there was no way to change the option to not load the front panel for certain particular subvi's in Application Builder--the option was grayed out.

For problem 1, I decided not to worry about linking the files dynamically in the Application Builder, but to just make sure the Application Builder would include their front panels. For problem 2, I had to figure out what was making Application Builder force the front panels to be included when I deemed it unnecessary, so that I could fix them not to be included. Basically then, going through my VI's that were forcibly included, I came up with a list of stuff I began checking for each time I would run into one where I didn't want to include the front panel. I have attached my list to this post.

My solution for problem 1 was then to use a customized appearance for my static-linked / dynamically loaded VI's, and disable the menu bar (forces the front panel to be included by Application Builder without changing appearance, since I never actually see the FP). My solution for problem 2 was often to remove property nodes referencing text on the front panel controls. Sometimes I was able to perform a numeric->text or enum->text conversion instead of referencing the text of the control itself, and sometimes I realized I didn't want anything to change and that it was ok to include the front panel so I could (for example) get a list of strings for my enum control.

I have attached the reference list I came up with of things to check for to make sure your VI properties are set correctly if you are trying to get Application Builder NOT to include the front panel of your subvi. The list might not be complete, but it's helped me to narrow down things very quickly and find the problems I was having.

[rolfk]

---

@m3nth wrote:
Problem 1) Some of the front panels were being removed for dynamically loaded VI's, which were not set as dynamic VI's in the Application Builder, but which were static-linked VI's in the program (so they were loaded in memory as linked subvi's but called dynamically). When the Application Builder decided to remove the front panel for those VI's, there was an error when loading them dynamically.

---

This is expected behaviour. The application has no way of knowing that these VIs will at some time be called dynamically. That would require analysing and understanding the entire program and in cases where you calculate the dynamic VI to be called at runtime it still wouldn't be feasable to do so.

---

@m3nth wrote:
Problem 2) Some of the front panels were NOT being removed for subvi's that I didn't want to have their front panel built into the compiled program. Loading front panels that are not needed uses extra memory, but there was no way to change the option to not load the front panel for certain particular subvi's in Application Builder--the option was grayed out.

---

There are several reasons why a front panel is needed. One of them is when the VI is called dynamically, even if the FP is never displayed and AppBuilder will account for that for VIs which have been added as dynamic VI to the project.
The other is when a VI uses some Property Nodes or Attribute Nodes as they are called now.

So to solve your problem 1) you could also just drop some property node in the diagram of such VIs and be done with it.

Rolf Kalbermatter