"Remove Panel" in Application Builder?

Hi,
I don't really understand the purpose of the Remove Panel feature in the vi settings tab of app builder. It says if you are dynamically loading vi's, then you must set this to "no", which I have found out your app will not work if you don't do this. But what happens when this is set to "no" and what happens when it is set to "yes"? Why not leave it to "yes" for all vi's? And where is the "source setting" for this? Thanks!

The reason for not leaving it to 'no' for all is easy. It consumes more memory. Both static (your exe grows) and dynamic (a copy of all front panel control and indicator data is made). so removing the front panel saves memory and can speed execution time.
Setting all to 'yes' wont work because then there will not be a panel for anything the user needs to see. in other words, you need at least 1 panel to be set to 'no'. If you use other input or dialog boxes, these must be set to 'no' also.
Read chapter 28 of the G programming manual, specifically pages 28-19 and 28-20 for front panel memory issues. The whole chapter is a must read, i think, but read at least these 2 pages.
Jared

Similar Messages

  • Can't remove Front Panels in Application Builder

    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.
    Attachments:
    ThingsToCheck.doc ‏61 KB

    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
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Sub Panel in Application Builder

    My VI has a sub panel with with a sub vi front panel displayed in it.  When I build my application the sub panel is no longer visible.  How do I get it to show up?
    Solved!
    Go to Solution.

    there is a simple subpanel.vi example you can take a look at.
    its in the examples.
    Best regards,
    Krispiekream
    Attachments:
    subpanel.llb ‏23 KB

  • Build settings "remove panel" option gray in application builder

    I am trying to create a stand alone application from my VI using application builder. My problem is I do not want a GUI front panel for it. In the application builder I go to "build settings" but the option to set "remove panel" to yes is gray and unselectable. Is there a setting somewhere that I need to change so I can select this? I can see that some of the VIs in my main VI have this as selectable. Any help would be appreciated.
    Steve

    Thank you, that took care of it.
    Steve

  • HT1925 When I try to uninstall my itunes I go to my control panel to remove the Apple "Application, Mobile Device, software support" then i get a pop up saying that "the feature you are trying to use is on a network resource that is unavailable" I cant fi

    When I try to uninstall my itunes I go to my control panel to remove the Apple "Application, Mobile Device, software support" then i get a pop up saying that "the feature you are trying to use is on a network resource that is unavailable" I cant find it. Its preventing me from re installing the new itunes.

    (1) Download the Windows Installer CleanUp utility installer file (msicuu2.exe) from the following Major Geeks page (use one of the links under the "DOWNLOAD LOCATIONS" thingy on the Major Geeks page):
    http://majorgeeks.com/download.php?det=4459
    (2) Doubleclick the msicuu2.exe file and follow the prompts to install the Windows Installer CleanUp utility. (If you're on a Windows Vista or Windows 7 system and you get a Code 800A0046 error message when doubleclicking the msicuu2.exe file, try instead right-clicking on the msicuu2.exe file and selecting "Run as administrator".)
    (3) In your Start menu click All Programs and then click Windows Install Clean Up. The Windows Installer CleanUp utility window appears, listing software that is currently installed on your computer.
    (4) In the list of programs that appears in CleanUp, select any Apple Software Update entries and click "Remove", as per the following screenshot:
    (5) Quit out of CleanUp, restart the PC and try another iTunes install using an iTunesSetup.exe (or iTunes64Setup.exe) downloaded from the Apple Website:
    http://www.apple.com/itunes/download/
    Does it go through properly this time?

  • Remove Application Builder while creating  workspace in Apex

    hi,
    am using apex in 11g database,am creating a workspace but it contain application Builder,Sql Workshop and Utilities..
    My objective is i want only sql workshop no need Application builder and utilities while creating workspace in Oracle Apex.
    guide me
    regards
    apex

    Ummm... OK. But why? If you only need a SQL tool why not use SQLDeveloper or some other tool? Is it that you want a web browser interface?
    It would be very unwise to try to remove the applications you mention from the apex installation. This is probably possible but potentially very risky as the stability of your apex installation is concerned.
    You might want to try taking a CSS approach and hide all the stuff you don't want to see via a custom CSS file that you could put in your installation.
    Earl
    P.S. If you're going to ask how to do this then it's probably not something you're ready to do.

  • Application Builder removing the menu and tool bar

    In Labview 8 we can use the application builder to disable the tool bar on the VI when during the build. Under Labview 8.2, the source file setting no longer affects the menu and tool bar of the top level VI. In my particuliar case, I want to remove the ability of a user to abort the VI from running after the application build, but I want the abort ability during the debugging phase.
    Under Labview 8.2, you have to alter the custom window for the VI. In the previous version, you can do it on the build module.

    Have you tried to set the properties of the Main VI being built?  It should default to these settings but you can still change them.  See attached picture from 8.20
    Matthew Fitzsimons
    Certified LabVIEW Architect
    LabVIEW 6.1 ... 2013, LVOOP, GOOP, TestStand, DAQ, and Vison
    Attachments:
    AppBuilder8_20.JPG ‏51 KB

  • Distant control panel with exe (builded application)

    I can connect to my vi if I run it with the development system (labview 7.1) on the distant PC, but I can't connect to the same vi if I run the "exe" I done with the application builder!!! I always have "network error".
    Is there something special to do?
    thanks
    Franck
    Je réussi à me connecter à mon vi si je l'exécute avec l'environnement de développement (7.1), mais impossible si j'execute l'appli que j'ai créé avec l'application builder. "erreur réseau" en permanence.

    Hi Franck,
    Do you use the remote panel connection ?
    You need start the web server to have access at your executable, see below links with information about this :
    http://digital.ni.com/public.nsf/websearch/862567530005F09C862567710044C3E2?OpenDocument
    http://digital.ni.com/public.nsf/websearch/862567530005F09C8025673000529121?OpenDocument
    http://digital.ni.com/public.nsf/websearch/3B2160B128EE09A886256B60006FFA66?OpenDocument
    http://digital.ni.com/public.nsf/websearch/A2A5ACDEEFA448E686256D9800629227?OpenDocument
    Let me know, if your problem was resolved with this links.
    Regards,
    Christophe S.
    FSE East of France І Certified LabVIEW Associate Developer І National Instruments France

  • Passing arrays with Call Library Function does not work after application builder

    Calling a DLL with Call Library Function which requires an array of data works correctly in Labview, but after building an exe with application builder, the call no longer works.  Dereferecing the pointer in the DLL retuns all 0s and not the actual values.
    Solved!
    Go to Solution.
    Attachments:
    TEST.zip ‏28 KB

    I did not run your code because it is a little unclear to me what it does.
    Two things:
    First, is the DLL you are calling the DLL-ified version of PopUpNames.vi? Then the problem is likely that the panel is not being built into the DLL.
    When LabView builds an application / dll, it strips the front panel and block diagram from all VIs that it doesn't think need to show a panel at run time. This reduces file size and increases code security. The App Builder's panel inclusion logic can be overridden by Build Specifications -> Source File Settings -> Remove front panel. A better method is to put a property node on a control in a window you want to show marking it "visible"; this is sufficient to tell the App Builder it should keep the panel.
    Currently Source File Settings shows "no dependencies" (clearly incorrect---another evil side effect of Express VIs I guess) but if you change the settings as shown below to keep ALL panels, one might hope the App Builder can figure it to keep the panel when it deconstructs the Express VI. (Alternatively convert the Express VI into a regular one.)
    A second comment: I am a bit flummoxed at the larger goal here. You are calling LabView DLL from LabView, which doesn't make a lot of sense, so I assume your larger goal is to call LabView from C or vice-versa. In that case be aware that your DLL is x86 (32-bit) but you are passing 64-bit ints as your pointers. In this case it is 32-bit LabView with 32-bit pointers in embedeed in 64-bit containers calling 32-bit LabView with 32-bit pointers in embedeed in 64-bit containers, so it all works, but if your going to call this from C or whatnot you're going to have to follow that same design.
    When calling C code the LabView Call Library Function does have a "unsigned pointer-sized integer" data type that always appears to be 64 bits in the dev env but which actually passes a 64 or 32-bit int to the DLL depending on the environment. The "pointer sized int" has to be 64 bits in the "LabView" part of the code because LabView's strong typing requires the data type to be determined at compile time. Casting all pointers to the largest data type in LabView makes it possible to write platform-independent code, but down at the Call Library level you still have to put the right number of bytes on the stack.

  • Display Bug in LV 8.20 Application Builder

    There seems to be a minor bug in the displaying of the "VI Settings" in the application builder for LabVIEW 8.20.
    The problem is in an executable build spec, in the "Source File Settings" category.
    Select a sub VI in the tree, then uncheck the select box for the "Remove Panel" property. Now select any other VI in the tree, then go back to the one you unchecked the "Remove Panel" box. You should see that the box is now checked.
    If you don't do anything else and just select "OK, then go back into the build spec, you'll see that the property was correctly saved as unchecked. So it looks like it's just a display problem.
    I've made sure the VI I try this with does not use any property nodes and it is not marked as a dynamic VI. I can reproduce this on two machines running Windows XP Pro SP2 and LabVIEW 8.20.
    Ed
    Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
    Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.

    In addition to Ed's
    comment, I would like to say that this unexpected behaviour is not
    always appearing. I have just seen following while editing this text :
    I have unchecked the Remove Panel box for all the UI VIs (all are
    located in the same directory). When scrolling through the different UI
    VIs in the Soure File Settings, the box was unchecked for all the VIs.
    Without closing the Source File Settings window, I switched to
    Developer Zone and switched back to the Source File Settings. For some
    UI VIs, the Remove Panel box was checked. I closed the window and
    opened it again, the box was unchecked again for all the UI VIs.
    But I have also encountered the case that when scrolling through the
    VIs to try to uncheck this setting for all of them, it suddenly appears
    checked again for a VI for which it was unchecked or unchecked for a
    before checked VI.
    You finally end with a very unclear situation and it may be that the
    Remove Panel is really checked for some VIs. At least, in some cases,
    the built EXE could not run because of missing front panels. I can't
    remember the exact error messages when running the EXE but they
    mentionned the name of the VI and something about missing ressources. I
    opened the .lvproj file and noticed that the "Remove Panel" property of
    these VIs was set to TRUE. After modifying these settings and
    rebuilding the EXE, it ran as expected.
    In development, I
    normally uncheck "Allow user to resize window" of the UI VIs because
    this setting can unfortunately not be changed when configuring the
    executable. In the "Source File Settings" I uncheck all options of "Use
    VI Setting" for these UI VIs and I only check "Auto-Center" (all VIs)
    and "Window is Modal" (some VIs).
    There is another problem with the application builder that I would like
    to mention. For (at least) following settings, the development settings
    of a VI will not be overwritten by the Source File Settings when
    building the executable :
    - Window has title bar
    - Show Menu bar
    - Show Toolbar
    - Show Scroll Bars
    This is also very annoying because you will need to change these
    settings in the development environement in order to get the expected
    appearance in the executable.
    LV8.2 English / WXP SP2

  • Problems with Application Builder and NI-DAQmx drivers in Labview 8.2 Professional

    Hello everyone,
    I am trying to use the application builder to create an executable so that someone without labview is capable of a remote panel connection to connect to our test laboratory.  our test laboratory uses the USB Compact DAQ  9172.  I did find some other forums that ran into a similar problem where a computer that didnt have labview installed on it looked for a particular driver (nilvaiu.dll).  The common solution appeared to be when building the installer, include the current NI-DAQmx (8.3 in our case) option and then the clients worked fine.   My question is when i use the application builder to create an installation file for this application, i get a prompt to:
    Locate the "National Instruments Device Drivers - February 2006 Disk 1" distribution. LabVIEW needs to copy a component installed or updated by the distribution to continue building the installer.
    What is confusing is that the installation cd's in our laboratory are from August 2006 (501165N-03).  It didnt make sense to me that i would need to downgrade the drivers from a few months ago, but i've been wrong before.  We just upgraded from the full development to the professional version about 2 weeks ago to utilize the application builder function.  Has anyone else ran into this problem and could this be a limitation because we purchased the software with the academic discount?
    thanks in advance
    Chris

    Chris,
    My "fix" is brute force.  Backup everything.  Removing all the NI software takes a while.  Be sure to remove leftover directories and files. 
    Altering the windows registry takes seconds and is not hard if you know what you are looking for.  I've attached a screen shot with the NI entry selected.  This is what I  deleted on by machine.  The thing to remember is that the registry controls all the software on your pc.  Delete/alter the wrong entry and you have problems.  Worst case scenario is that you could end up formating the hard drive and starting over from scratch.  I'm not trying to scare you, but I want to make sure you understand the potential for harm. 
    One thing you might try first.  NI-DAQmx 8.5 is now available for download from NI.  You might try unloading 8.3 and installing 8.5. 
    Attachments:
    regedit pic.JPG ‏102 KB

  • [svn:fx-trunk] 9419: 2nd attempt to check in prototypes of ControlBars in Panel and Application , Spark Containers in Halo Navigators, Halo ViewStack in Spark ButtonBar.

    Revision: 9419
    Author:   [email protected]
    Date:     2009-08-20 09:19:04 -0700 (Thu, 20 Aug 2009)
    Log Message:
    2nd attempt to check in prototypes of ControlBars in Panel and Application, Spark Containers in Halo Navigators, Halo ViewStack in Spark ButtonBar.  APIs should match spec but are subject to change from PARB.  Skins are subject to tweaking after XD review
    QE Notes: The following tests will fail and need updating:
    gumbo/containers/Panel/Properties/Panel_Properties_position Panel_Properties_rotate
    apollo/spark/components/Window/properties/window_properties_titleIcon_tests titleIcon_test8
    Doc Notes: None
    Bugs: None
    Reviewer: Darrell, Glenn, Ryan
    API Change: No
    Is noteworthy for integration: No
    tests: checkintests mustella/gumbo/components/Application, gumbo/components/ButtonBar, gumbo/containers/Panel, apollo/gumbo/spark/Window, containers/ViewStack, containers/Accordion,
    states/Integration/TabNavApp, states/Reparent
    Modified Paths:
        flex/sdk/trunk/frameworks/projects/airframework/src/spark/skins/spark/SparkChromeWindowed ApplicationSkin.mxml
        flex/sdk/trunk/frameworks/projects/framework/src/mx/containers/Accordion.as
        flex/sdk/trunk/frameworks/projects/framework/src/mx/containers/TabNavigator.as
        flex/sdk/trunk/frameworks/projects/framework/src/mx/containers/ViewStack.as
        flex/sdk/trunk/frameworks/projects/framework/src/mx/controls/NavBar.as
        flex/sdk/trunk/frameworks/projects/framework/src/mx/core/Container.as
        flex/sdk/trunk/frameworks/projects/framework/src/mx/events/FlexEvent.as
        flex/sdk/trunk/frameworks/projects/framework/src/mx/managers/FocusManager.as
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/Application.as
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/ButtonBar.as
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/Panel.as
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/SkinnableContainer.as
        flex/sdk/trunk/frameworks/projects/spark/src/spark/skins/spark/ApplicationSkin.mxml
        flex/sdk/trunk/frameworks/projects/spark/src/spark/skins/spark/PanelSkin.mxml
        flex/sdk/trunk/frameworks/projects/wireframe/src/spark/skins/wireframe/PanelSkin.mxml
        flex/sdk/trunk/frameworks/spark-manifest.xml
        flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/mxml/builder/ComponentBuilder.jav a
        flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/mxml/lang/StandardDefs.java
        flex/sdk/trunk/modules/compiler/src/java/flex2/compiler_en.properties
    Added Paths:
        flex/sdk/trunk/frameworks/projects/framework/src/mx/core/IDeferredContentOwner.as
        flex/sdk/trunk/frameworks/projects/framework/src/mx/core/INavigatable.as
        flex/sdk/trunk/frameworks/projects/framework/src/mx/core/INavigatorContent.as
        flex/sdk/trunk/frameworks/projects/spark/src/spark/components/NavigatorChild.as
    Removed Paths:
        flex/sdk/trunk/frameworks/projects/spark/src/spark/core/IDeferredContentOwner.as

  • Scrollbar bug in application builder

    I seem to have found a bug concerning the front panel scrollbars when creating an executable with application builder.
    My vi runs fine in Labview. It also runs fine as an executable with everything at defaults.  
    However, trying to remove the scrollbars from the front panel, I can build executables that hang up upon running. 
    Executable hangs up when:
    - setting the vi property 'windows appearance' to dialog.   (application builder set to use vi settings)
    - in application builder, sourcefile setting:  setting 'use scrollbars' to  "don't use vi settings" and value "not checked"
    What's really weird is that sometimes those troublesome executables do work.   The executables compiled with the 'dialog' option only seem to work once, and then not anymore.    While the one with the no-scrollbars option set in application builder seems to hang the first time, but work fine after that.   Except that it does show scrollbars....
    The executable does work without front panel scrollbars when setting the vi property 'windows appearance' to 'top level application' and application builder settings to 'use vi settings'.

    Hi Rebecca.   
    I'm using Labview 8.2  on Windows XP SP2 for developing.  The PC that the .exe should run on has the LV 8.2 runtime installed, also on Windows XP SP2.  
     I've attached two executables of my program:  'works'  and 'doesn't work' which were compiled with the scrollbar on and off.  Also included the source distribution.  The "Micro4 Advanced Multiple Injections LV82" is the main program.   (Hope I did the distribution right... it's the first time I'm using this project thing...)
    I've been testing a bit more myself...  I now noticed that both .exe's work correctly on my developement PC, but only the one works on the runtime PC...    
    Attachments:
    doesn't work.zip ‏220 KB
    My Source Distribution.zip ‏336 KB
    works-ok.zip ‏400 KB

  • Can not set "Remove Panel" to "No" for dynamic VI

    In the VI Settings tab of the Application Builder, has no row for my dynamic VI. How to add this row for my dynamic VI.

    Are you sure that you added the dynamic VI on the Source File tab? I can't reproduce the problem where the dynamic VI doesn't show up in the VI Settings but it is possible that you can't set Remove Panel because of settings in VI Properties.

  • Deployment vs Application builder

    Hi there, I just need a little help getting something straight in my head.
    I've been developing a test-sequence-program on my PC here, which will sooner or later be put into the factory. We don't really want a labview licence sitting out in the factory, so I'm looking at my options regarding building standalone executables. I'd be very appreciative for any help with the following questions:
    a) Deployment vs Application Building - what is the difference? I have the Labview 8.2 Full Version, and would prefer to avoid buying a separate application builder if the Full Version does the trick already.
    b) Say I have some controls on the front panel (eg. "maximum voltage allowed"), which I want to set on startup - I don't want the people using the tester to be able to change this afterwards though.. is it possible to add command line switches?
    eg. myprogram.exe -maxvoltage 20
    Thanks in advance.

    If you want to run your application on a computer that does not have LabVIEW installed, you need to create a standalone application using the application builder. The application builder is not included in LabVIEW full (only professional and higher), so you would need to purchase this seperately.
    Yes, it is possible to add commandline switches. In the application builder, you should specify to pass all parameters to the application. In your code you can read the commandline parameters and do whatever you want with that information.
    From the online help:
    Pass all command line arguments to application—Passes all arguments as user-defined arguments to the application when you launch it from the command line. If you remove the checkmark from this checkbox, only the arguments after two hyphens (--) in the command line pass to the application as user-defined arguments. Use the Application:Command Line Arguments property to read the user-defined command-line arguments passed when the application launches.
    LabVIEW Champion . Do more with less code and in less time .

Maybe you are looking for