JaysonR

That is definitely what we have desired, but that definitely a lot more complicated to do correctly. I think it's safe to say that won't be in SP1, but you'll get a fix for your issue

I have taken ownership of the CAR and will try to see that it gets fixed in SP1.

I understand that it is annoying, and I will try my best to make sure it gets fixed. Why do you need to change the names back again? In the meantime, is it not possible to just pick names that will allow it to be sorted the way you want it all the time?

I assume that the reason it's out of order might be that build specs are sorting by either name, path or type? Perhaps a workaround would be to name the build specs in such a way that when you sort them alphabetically, it will put them in the order you'd want to build them? I see what the problem is, and I will make sure that it gets addressed ASAP. Hopefully in the meantime, you can make use of the sort order option. To do this: right click on the build specifications node and select "Arrange By" and pick name. That should do an alphabetical sort. You can also sort by type, but then installer wouldn't come in last. You should be able to drag/drop the build specs, but it seems like you aren't able to drag/drop build specifications. I will make sure this gets fixed.

I guess I'd just really need to understand your setup to see if there's anything we can do about it. I'm not sure if there will be a solution for you, but there might be. I will also relay your feedback to see if there's something that can be done about this in the future.

The LabVIEW 8.0 run-time engine registry entry is at: HKEY_LOCAL_MACHINE\SOFTWARE\National Instruments\LabVIEW Run-Time\8.0 There is a key called Path in there. That will point to where the run-time engine is installed on the system. Hope this helps.

I just double checked and am afraid to report that you will be stuck with 2 copies of the INI file.

Well if you only intend to put the Tescom.ini file in the WINNT directory for the installer, you can specify that in the installer editor. Rather than adding it as a file to include in the EXE editor, do the following: On the installer, go to the Source Files page. Expand My Computer and find your Tescom.ini file. Add it to the corresponding MSI variable for your WINNT directory. If it doesn't exist, I believe you can create a new directory mapping to add it there. Hope this helps.

Yeah, the new application builder is somewhat different than the old one. With the installer, adding a build specification adds everything from the build specification to the specified directory. The output is treated as an atomic entity. If you want to have your ini file moved to the WINNT folder, you need to add it as an item from the project, not the build rule. The same type of thing needs to be applied to the lvXXX DLLs. I don't believe there is another way for you to get around that one. I'll take these comments and run it by some people to see if something can be done about this in the future.

The easiest way to make sure that your changes are reflected in the project is to always have the project open when you make your edits. Basically, always start with the project window open, and open all VIs from within the project. I know it takes some getting used to, but I think that it will prove to be useful. As far as the error when building an executable, I'm working on having better error reporting. However, this problem shouldn't come up too much as long as the project is open when making all of your edits or name changes. As far as the installer issue, the installer should preserve the hierarchy of the build output. So by including the build specification, the data directory and other directories created as specified by the build specification should automatically appear on the installed system. The only catch is if you create a folder that goes beyond the root level of the MSI directories listed. Other than that, the hierarchy should be preserved. How is your build specification configured? Perhaps there's just a misconfiguration that is causing the installer to dump all the files in to one directory.

Having an INI file isn't necessary. In fact, unless you specify an INI file to be copied over (in versions 7.1 and below), the application builder doesn't create one for you. The INI file is created when the application is first launched. The INI file contains settings similar to that of the LabIVEW.ini. It has settings that can help with webservers, VI server access and other settings that deal with colors for graphs and other user defined options. However, not all settings are stored in the INI file of the application. There are also tokens that can be used to specify what run-time engine is used when the app is run. A lot of people won't find the INI file all that useful, however there are some definite use cases for them.