gmart

@Stobber. Direct modifications of the tags is not recommended and not supported. There is no documentation for those tags.

Ideally, I would like to place the build in a folder that incorporates the version in the name. Check the LabVIEW 2013 Upgrade Notes: Creating Directory Versions in Build Specifications In LabVIEW 2012 and earlier, if you create a build specification, LabVIEW does not include the build version number in the directory path on disk. In LabVIEW 2013, you can use tags in the build destination path so LabVIEW automatically includes the build version in the directory path. You can include the [VersionNumber] tag in the Destination path field on the Destinations page or the Destination directory field on the Information page of the build specification properties dialog box. Installer builder has the same functionality but uses the tag [ProductVersion].

I did not see a File->Locate in Project. There is a View->This VI in Project (CTRL+SHIFT+E) which is present in 2010 and 2011 that does what mention. Perhaps the menu item you referenced was a tool added to 2010?

Starting with LabVIEW 2010, build specifications will copy any errors codes to the run-time engine location by default. This setting is located in the Advanced page. If you do not need to copy the error code files, you can uncheck this option.

Building a "release" executable remove front panels and block diagrams of all dependencies. Block diagrams (but not front panels) are removed of all Startup and Always Included VIs. For a debug executable, all front panels and block diagrams are kept and debugging is enabled for all VIs. There are no concept of "symbols" for LabVIEW built applications so that is not part of a build. So the larger size of your application is due to the inclusion of front panels and block diagrams.

The internal format of executables changed in LabVIEW 2009. By default, though, older projects load using the older format. You can toggle this setting on the Advanced page. Look for the option - "Use 8.x file layout". Uncheck this (if it's checked) and the files will no longer be placed outside the EXE.

I think the behavior you are seeing is due to the creation of a new build specification (which you did coincidentally in 2009 SP1). I created a new EXE build specification for a caller VI that has a subVI configured as you specified. Going all the way back to LabVIEW 8.2, when a new EXE is built, the resulting app returns the error you referenced. This actually makes sense since the application builder does not know that the VI needs to have its front panel included because of that setting. Adding the VI as Always Included forces the front panel to be kept and thus the application works. It's possible that in the "working" situation, the building specification in that project has the setting such that the front panel is kept on that particular VI.

Apps built in 32-bit LV will be 32-bit. Apps built in 64-bit LV will be 64-bit. If a VI was saved by 32-bit LabVIEW it will recompile in 64-bit LabVIEW and vice versa. Built apps are saved in the version of LabVIEW used to build so even if source VIs were saved as 32-bit, when built by 64-bit LabVIEW, the output will be 64-bit (and again vice versa with 64-bit source and 32-bit LabVIEW). So in theory, you could use the same source with 32 and 64-bit LabVIEW and your output will be as expected.

Have you seen this? - Darren's Weekly Nugget 11/09/2009

It's usually difficult to reproduce 1502 errors since their root cause is typically unique to the setup that has a problem. In order to track down the root issue, I would say try to get a set of code that reproduces the problem and submit that to NI support for evaluation. Regarding the error 6. What were the circumstances where the error occurred? Was the user's destination path for his built very long? What OS? What modules/toolkits were involved? Again, reporting this information also helps with tracking down the problem.

Just to be clear. The only thing that changed between the build working and not working was the installation of SP1? You made no other changes to the code? What is the make up of your top-level VI? Does it use classes, variables, drivers, Mathscript etc?

Each SCC provider implements functionality for operations such as Check Out, etc. For Clearcase, for example, getting a project means defining where the local working path will be. So Perforce's implementation displays this dialog. Typically, other IDEs pass in the path of the working project (in the Visual Studio case) and so you don't usually see this dialog. LabVIEW does not require projects but Perforce requires this parameter, so the dialog is required. I would check with Perforce for more information on the dialog.

The Perforce dialog displays the depot structure of the selected clientspec. All you should have to do is select a folder or file in the depot list. There is a known issue with version 2009.1 of Perforce which behaves as you have described. Previous versions have allowed you to select either files or folders. For now, I would select a file under the depot location.

You can post your issue in the NI Forums. Those forums are regularly checked by applications engineers. Also you can open a service request via this - link. While NI developers do frequent the LAVA forums and occasionally provide support, the above are the "official" channels.

There is a VI in the File I/O>>File Constants palette - Application Directory - that will return the path to the directory containing the application. This will work in the development environment as well as an application. You can use this VI to build the appropriate path to your ini file. Also, there is an option in the Advanced page "Use 8.x file layout" that will keep the layout of the application flat. It is mainly there for compatibility since the hierarchy layout is the standard.

If you can reproduce this behavior, it would be good to report that to NI support for evaluation.

I've been Alfa bombed as well.

What do you mean by your source tree is well defined? What I suggested doesn't require you to change your source layout. All you'd need to do is change the destination directory in the build spec to a shorter location (ex. C:\temp). That should reduce the destination path lengths. If the output needed to be at a certain location for other build tools, you could write a VI to copy the files from the new location back to the old location.

The word "corruption" is scary and not really what is happening during the build. We get an error while building due to OS limitations. Nothing is corrupted. Words mean things and the last thing we need is someone googling this problem and seeing the word "corruption" . Regarding the long path names, one thing you can do to mitigate the problem is to change your destination directory to something shorter. I know that may not be possible in all cases, but that will buy you some extra characters. Alternatively, you can quit being so descriptive with path names and go back to the DOS days of 8.3 filenames .

In general Windows (and Mac and Linux I believe) have a character limitation for paths. In the past, some of that limitation was masked by the use of LLBs for the EXEs format. LLBs have special behavior (such as allowing characters in filenames that OS's don't like) that could let a name of a VI exceed the OS path limitation. Since LabVIEW knew how to deal with the path, it was ok. With the 2009 EXE, your concern about the path resolution shouldn't be an issue. Since we can't get into a path length problem due to OS limitation, LabVIEW will not have to deal with a path that's "too long".

With the new format for applications, files are stored relative based on the source files' layout. Because of this, it is possible for the destination file paths to get long while building. There is information on the change in the upgrade notes.

ESST, Thanks for the thorough response. The problem is due to the file named "CFG-I/O-Bytes.vi". It contains a slash which is not valid for the OS. This is not a problem if the VI is inside an LLB since that was allowed. During the process of building an application with the non "8.x layout", files are written to disk. Since that filename is not valid, the error results. The error was reported to R&D (# 158487). The workaround is to check the checkbox (which is the default when loading older projects). Also, you could try to rename the VI during the build process. You will need to have the files under My Computer so you can individually rename that one file.

ESST, Did your project also use the SPT toolkit? What was your exact error? It would be helpful to know this to better understand why toggling the checkbox worked for you.

I've been seeing this same behavior in Thunderbird. I thought I was going crazy so I'm glad to see it's not just me. I'm subscribed to - http://lavag.org/rss/forums/1-lava-forums/. I never had a problem with LAVA RSS until LAVA got updated.

What, you didn't find it on page 46 of the Upgrade Notes? "The Build Application from VI dialog box allows you to build an application from the VI you are currently editing."