Application builder changes tdms to excel vi

I had a tdms to excel vi that was working great. So I tried to make the whole program into an executable.  I have done this before without incident.  So I went to close the source program and it asked me if I want to save (most specifically the tdms to excel sub-vi).  It was more of a strongarm tactic since I couldn't close it without saving.  Now, both the executable and the source program open the first file, convert it to excel format (as intended) and close it again, but them fails to do it for any other files in the array that I generated.  A little trouble shooting.....  I opened other programs and ran them successfully.  upon converting them into an executable, it asks me to save changes to the tdms to excel vi, which, I never touched.  this resulted in duplicating the problem stated above.

thomas,
          I'm minorly confused so let me ask a clarifying question: Does the VI still function properly but you are just being prompted that "something has changed" by your source code control?
If it's just the "needing to save changes when none were made" issue and not that your code is no longer working then this article (http://zone.ni.com/reference/en-XX/help/371361J-01/lvconcepts/saving_vis_compiled_code/) might help explain why LabVIEW asks for changes. Even though changes aren't physically made by you, there are changes being made.
Grant H.
National Instruments
LabVIEW Product Marketing Manager

Similar Messages

  • Unable to open excel file through application created by application builder

    Hello,
    I've created an application for my program using application builder, but the built application  is not able to open the required excel file as it was being opened in original program.
    Please help.

    Please post your code. We cannot do anything to help you if you do not. There are too many things that could be wrong for us to try and guess what you are doing. Also please tell us which version of LV you are using and which version of the toolkit. This is important because there have been a lot of changes to the toolkits here in the last couple of years.
    Joe.
    "NOTHING IS EVER EASY"

  • Report Generation for Excel does not work after using the Application Builder

    I have a VI that writes data to an Excel file using the Report Generation Toolkit. I recently compiled the VI into a single Application (EXE) using the Application Builder. My VI runs its tests properly, but no data is written to Excel. What could be the cause? I don't receive any error messages.

    Hi
    I usually build exe-files, which sometimes also have report functionality.
    Open the Application Builder and check the following things:
    1. Add the following vis: _Word Dynamic VIs.vi, _Excel Dynamic VIs.vi They should be located in the directory ..\LabVIEW X.X\vi.lib\addons\_office in the llbs _wordsub.llb and _exclsub.llb (report1.jpg)
    2. If you use an Installer, go to the Advanced Settings. There you can select some things to include in the Installer. Check if "NI Reports Support" is selected. (report2.jpg)
    These are the things I always do, if I need reports and I never had problems up to now. I made two screen-shots of these settings.
    Hope this helps.
    Thomas
    Using LV8.0
    Don't be afraid to rate a good answer...
    Attachments:
    report.zip ‏25 KB

  • Application builder exe does not load excel

    I have used application property node and invoke node to cerate a set of VIs that read and write data to an Excel sperad sheet.  This works fine in when running in LabVIEW, however when I run myApp.exe as build from application builder, the data does not get logged to Excel.  The file dialog appears to  open the XL Spreadsheet but not data gets logged nor is any error reported?
    What is going on?   All the VI are in the same project folder?  Is there some additional addon run-time the must be installed on the target machine?  I am uisng LabVIEW 2012 on the development station with Win7 Pro and Office 2010 on both the devleopment station and the target system.  Is there one document that describes using Application Builder?   It was not clear that I needed both LabVIEW and VISA run-time engines to get my application.exe to run on the target.  Is there something simialr I must do to get Office to work as well? 

    I was finally able to track this back through by starting from scratch and received an error code, which led me to this post:
    https://forums.ni.com/t5/LabVIEW/Error-2147319779-Excel-ActiveX-and-Broken-LabVIEW-Icon/td-p/2354776
    Deleting the "1.7" items solved the problem.

  • It should be easier to change the default copyright company in Application Builder

    It should be easier to change the default copyright company in Application Builder.  
    I got the following from NI support to change the name of the company that is copyrighting the software.
    1. To show the desired hidden folder, you must select Tools>> Folder Options >> View >> Under 'Files and Folders'>> 'Hidden files and folders' >> check the 'Show hidden files, folders, or drives' >> Select 'ok'
    2. Navigate to C:\ProgramData
    3. Open ProgramData >> National Instruments >> LVProductDLLInfo >> 12.0.0 >>LabVIEW_ADE_120000.ini   ***Please note that the folder 12.0.0 may instead be 14.1.0 or another numeric value based on which version of LabVIEW you are using***
    4. Change the RegisteredOrganization and RegisteredOwner to the appropriate organization and owner respectively.
    The fix NI support sent me was to change the name of the current software owner.
    The company that owns the software is usually writing the program for another company that is paying to have it developed. If the software owner is not careful they may assign the copyright to their company or to the company that they developed software for last.   I am sure that the company that had software developed will be surprised if their name is not listed as the legal copyright owner.
    Stan

    I've found it now (sheepishly). It is a parameter defined in Home->Application Builder->Application 693->Application Attributes->Edit Definition. I thought it was using the database nls parameters, but it isnt. So I simply had to change the parameter value from $ to £.

  • In application builder the top level vi is always set to "run when opened"; how do I turn this off so I don't have to change it each and every time I build a .exe??

    I build a lot of executables using Application Builder under LabVIEW and in every one I build, I don't want the top level vi to take off and run when I open the executable. Currently, I edit each .exe I build within Application Builder and change the option of "run when opened" from Yes to No for the top level vi. All the other subvi's are already set to No. It would seem as though there should be some way to "turn this off" if you will so the top level vi is not always set to "run when opened" by default within Application Builder. Is there such a solution that anyone knows of?? Any help would be apprec
    iated... thanks...

    Indeed the Application builder forces "run when opened" to true for top levels VIs. If you don't want your VI to make any real work when the application starts, you should simply put a do-nothing loop in the beginning of the VI that will loop until the user presses a boolean. It will be more intuitive for users to press a Run button on the FP than clicking on the white Run arrow in the bar.
    LabVIEW, C'est LabVIEW

  • Change the application builder's language

    Is there a way for developers to change the application builder's language?
    My location is in Germany but I prefer the american-english language during development; in case of normal usage of my Apex-Appl. (as a normal end user) I'd like the "german way"...

    Hello,
    If you look in the Oracle® Database Application Express Installation Guide, paragraph 4.7 :
    The Oracle Application Express interface is translated into German, Spanish, French, Italian, Japanese, Korean, Brazilian Portuguese, Simplified Chinese, and Traditional Chinese. A single instance of Oracle Application Express can be installed with one or more of these translated versions. At runtime, each user's Web browser language settings determine the specific language version.
    The translated version of Oracle Application Express should be loaded into a database that has a character set that supports the specific language. If you attempt to install a translated version of Oracle Application Express into a database that does not support the character encoding of the language, the installation may fail or the translated Oracle Application Express instance may appear corrupt when run. The database character set AL32UTF8 supports all the translated versions of Oracle Application Express.
    In the rest of the doc there is a description how to install other languages...
    Greetings,
    Roel
    http://roelhartman.blogspot.com/
    http://www.bloggingaboutoracle.org/
    http://www.logica.com/

  • How to change Application Builder colours?

    Hi all
    I would like to change the colours of the application builder on my live server - just so I don't get confused when I have sessions to both live & development. It could be as simple as changing the logo bar to a different background colour, so long as it makes it obvious which server I'm working on!
    I guess it is a matter of changing the theme but I'm not sure where to look?
    Thanks in advance
    Steve

    Hi,
    As I know there is no out of box solution to change builder theme.
    Probably safest way is change css files in HTTP server /i/css
    But I would not bother to do it
    Have you think set instance messages?
    http://download.oracle.com/docs/cd/E17556_01/doc/admin.40/e15521/adm_mg_service_set.htm#sthref361
    You can write HTML there also and add e.g. some images.
    Or if you use Firefox, you can write some client side greasemonkey script to alter look of builder.
    Regards,
    Jari

  • The executible I build with the application builder does not function the same as my VI file.

    I am using a USB 6008 device with the newest DAQmx drivers and Labview
    8.2 to make analog voltage readings.  Within my main VI I first
    create a data folder in the same location as the VI using a property
    node and then use case statements to call two sub VIs that create a
    data file within the data folder and then collects data.  When I use the
    application builder to create an executible the resulting file does not
    operate the same as the origional VI.  The program appears to be
    reacting to button presses on the GUI, but there is no indication that
    the data folder is being created or that any measurements are buing
    made.  Are there any known issues that may account for this
    anomily?
    -Mike
    Message Edited by TMBurleson on 10-16-2006 03:09 PM

    Are you using the VI Path property, using a reference to the current VI?
    I could be wrong, but if you're attempting to use a path relative to the current VI, I think that does indeed change in a built application. If your VI used to be C:\somewhere\foo.VI, then after building its path would actually be C:\somewhere\foo.EXE\foo.vi . Thus, if foo.VI used to try to make a folder like C:\somewhere\datafolder, the built application would be trying to make C:\somewhere\foo.EXE\datafolder , which wouldn't work.
    This is sort of a shot in the dark, but does this sound like it might be the case?
    EDIT: Dennis beat me to it.Message Edited by kehander on 10-16-2006 03:26 PM

  • 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.

  • Application Builder for labVIEW 7 Doesn't support any report generation function

    I'm Using LabVIEW 7.0 to build an application My Application is exporting data to an excel report. the vis were working great until i tried to creat an .EXE file. The application is working fine but when i try to generate the report nothing happens.
    So, I decided to test the report generation functions alone (New Report.vi, Append report text.vi and Dispose Report.vi). The Problem Still there, the .EXE file takes no action when i attend to generate a report. any suggetions please.

    Shady Yehia wrote:
    > I'm Using LabVIEW 7.0 to build an application My Application is
    > exporting data to an excel report. the vis were working great until i
    > tried to creat an .EXE file. The application is working fine but when
    > i try to generate the report nothing happens.
    >
    > So, I decided to test the report generation functions alone (New
    > Report.vi, Append report text.vi and Dispose Report.vi). The Problem
    > Still there, the .EXE file takes no action when i attend to generate a
    > report. any suggetions please.
    Another possible reason besides of possible path problems: Are you
    running that application on the same computer? If not you need not only
    to install the Runtime-Engine (automatic when you create an installer)
    but also the Report Active X support.
    To include that into the installer
    you go into the Installer Settings Tab, then press the Advanced button
    and make sure that you check the NI Reports Support checkbox before
    creating an application build.
    Rolf Kalbermatter
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • "An error occurred sending the command to the application" When trying to open excel document from outlook 2007

    Error message "An error occurred sending the command to the application" When trying to open excel document from outlook 2007.
    OS: Windows Server 2008 R2
    If I save the document then it opens fine, messing with default file associations does not resolve this problem, I've googled for ir it and some suggest unticking compatibility mode or "run as admin" for excel application, neither is selected in my case.
    Outlook is configured to run as remote application from remoteApp server, this error is only occurring for one user, for others excel documents open just fine.

    Hi
    Thank you for using
    Microsoft Office for IT Professionals Forums.
    From your description, we can Create a trusted location follow these steps
    Click the Microsoft Office Button , and then click Excel Options.
    Click Trust Center, click Trust Center Settings, and then click
    Trusted Locations.
    If you want to create a trusted location that is not local to your computer, select the Allow trusted locations on my network (not recommended) check
    box.
    Click Add new location.
     IMPORTANT   We recommended that you don't make your entire
    Documents or My Documents folder a trusted location. Doing so creates a larger target for a hacker to potentially exploit and increases your security risk. Create a subfolder within Documents or My Documents, and make only that folder a trusted location.
    In the Path box, type the name of the folder that you want to use as a trusted location, or click Browse to
    locate the folder.
    If you want to include subfolders as trusted locations, select the
    Subfolders of this location are also trusted check box.
    In the Description box, type what you want to describe the purpose of the trusted location.
    Click OK.
    More detailed information you can refer to this link:
    http://office.microsoft.com/en-us/word-help/create-remove-or-change-a-trusted-location-for-your-files-HA010031999.aspx?CTT=1#BM12
    Please take your time to try the suggestions and let me know the results at your earliest convenience. If anything is unclear or if there is anything
    I can do for you, please feel free to let me know.
    Hope that helps.
    Sincerely
    William Zhou CHN
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

  • 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

  • I have a application build in labview 8.5 for Windows XP using NI Visa functions to interact with hardware , how to make is work in Windows 7 32 bit and Win 7 64 bit

    I have a application build in Labview 8.5 which wroks fine with Windows XP , this program uses basic read /write functions of NI Visa to communicate with Hardware . This application doesnt work with Windows 7 32 bit/64 and Vista . What changes i need to do to make it work for the said operating system

    srinivas wrote:
    Sorry for confusion ,
    My question is what changes i need to do in code or while making the installer to make the existing program work with other Windows operating system
    You need to make sure the machine have the corresponding NI-VISA installed. Check in the NI software pages for the right version.
    Also make sure that the com port's can be selected when you first start the application. Eg. if you refer to VISA "COM1" on the XP machine It might be "COM2" on the Win7 machine.
    Br,
    /Roger

  • Error message "VI is not executable"! Need help with Application Builder

    Hello,
    I have a problem with an application, built with the Application Builder. I have read some threads about the problem I have, but I still don't know a solution.
    When I run my front panel from LabVIEW, everything is good. So, now I created an application (and an installer) to be able to run it on other PCs as well. This application does not work. Everytime I start it on my PC, I get the error "VI is not executable. ...". I read in several forums solutions for this error, but I cannot fix it! I've changed my properties for the builder, but with no success. Perhaps, anybody has more ideas, what's the problem.
    To get a better idea from my project, here a little description of it:
    In the block diagram there is a while loop which is continuously runned. In this loop I only set some properties for the layout of the front panel, such as decorations which will be hidden/shown and changes of colours of indicators... For the rest, it waits for a click on the button "Start" in the front panel. After that, a DLL is called to communicate with a USB device. Some measurements are carried out and the DLL is closed. I hope, you can get a global idea from my block diagram...
    I use LabVIEW 8.5, the DLL is a third-party DLL, which we wrote on our own. But I think the DLL works properly, if it is called from a C# application it works and it works, too, by calling it from LabVIEW when I am in development mode.
    It's a project for university and I'm just a beginner in LabVIEW, so I don't have so much experiences in it, but I think i improved my knowlegde about LabVIEW very well in the last weeks!
    So, i hope to get an answer soon (the deadline for the project is not soooo far away )
    If you need more information, please let it know...
    I would be very grateful if there is someone with a working solution...
    Kind regards from the Netherlands,
    Sebastian

    Sebastian,
    Your architecture makes it very difficult to debug this and other problems.  Does the error message mention which VI is causing the problem?  It is very important to wire your error clusters everywhere.  In LabVIEW, when a node throws an error (Error.Status = T), future nodes do not execute.  At the end, place an error cluster indicator that you can see on your front panel.  When an error posts, you can right click the indicator (even in a compiled application) and select "Explain Error".
    This is a start, but you really need to push this into a queued-state machine before this gets any more complicated.  As it were, if anything in your loop hangs, your whole application hangs.  See attached for a queued-message handler (not advisable for actual applications, but you get the point.  You would want to have a type defined enum in lieu of strings, and shared data between states differently, etc.)
    -Jason
    Message Edited by LabBEAN on 01-20-2009 08:36 AM
    Certified LabVIEW Architect
    Wait for Flag / Set Flag
    Separate Views from Implementation for Strict Type Defs
    Attachments:
    State Machine.vi ‏18 KB

Maybe you are looking for