Keeping LV8 Project Explorer up to date on file changes?

[george seifert]

I'm wondering what is the best way to keep the new LV8 Project Explorer up to date on file changes. For instance I renamed a VI and forgot to tell the Project Explorer about it. When I went to build an executable I got an error saying it couldn't find a file. I finally figured out that the VI was missing in the Project Explorer because of the name change.

It sure seems like I have to do a lot of baby sitting for this new system that I didn't have to do before. For instance the old app builder would automatically figure out which VI should not have their front panels removed. Now I have to manually go through and figure out which VIs should not have it's front panel removed.

Am I missing something about how to manage a project or is this new system really a lot more work?

Another problem: How do I get the LV8 installer to put the files in the same place as the application builder? The app builder lets you specify which folders to place the file in whereas the installer seems much more limited. If I include the exe listed under the "Build Specifications" on the Source Files page of the installer it puts all the files in one directory.

There seems to be no way to get installer to create the same file structure as the app builder. What am I missing?

George

[JaysonR]

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.

[george seifert]

Thanks for the suggestions. I'll try to remember to open everything from the project explorer.

I've attached a Word doc that shows two screen shots. The first is from the application builder. The second is from the installer. In the application builder note the file Tescom.ini in the WINNT folder. That's where I want it. Now in the installer note that the Tescom.ini file is in the CP Dispense/Code dir (because it's included in the Executable files) and I added it under the [WindowsFolder]. If I don't manually add it under the [WindowsFolder] the installer only puts it in CP Dispense/Code dir. So now when I do the install the Tescom.ini file gets put in two directories. That didn't happen to me with the 7.1 app builder.

Also note that in the application builder the lvxxx.dll files get put in the data dir (defined as my support files dir). I don't want them there. I'd rather have them in the Code dir. The old installer let me pick where they go. I don't see any way to specify where they go now. In the installer however they do get put in the Code dir. So in the end they do go where I want them, but I don't understand why I can't have a consistent directory structure between the application builder and the installer.

George

Download File:post-2786-1130881381.doc

[JaysonR]

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.

[george seifert]

Jason,

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

Sorry I don't follow what you mean here. In my build spec for the executable I tell it send the Tescom.ini file to the WINNT dir. If I build just an executable I don't know how else to tell it where to put that file. And since I need to build the executable before I can run the installer I'm stuck with the structure in the build spec.

George

[JaysonR]

Jason,

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

Sorry I don't follow what you mean here. In my build spec for the executable I tell it send the Tescom.ini file to the WINNT dir. If I build just an executable I don't know how else to tell it where to put that file. And since I need to build the executable before I can run the installer I'm stuck with the structure in the build spec.

George

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.

[george seifert]

Jason,

We seem to be going in circles a bit. I understand how I can add a variable to my WINNT directory in the installer. However that same file is also included in the directory with the executable because it's part of the executable build script. I have it as part of the executable build script so I can test how the program functions without having to run the installer. So now the file gets put in two places when I only want it in one place. Unless there's a way that I'm missing to tell the installer to put just the executable in a particular folder, it seems that I'm always going to have to have two copies of files if I want to have files installed in directories other than where the executable is.

George

[JaysonR]

Jason,

We seem to be going in circles a bit. I understand how I can add a variable to my WINNT directory in the installer. However that same file is also included in the directory with the executable because it's part of the executable build script. I have it as part of the executable build script so I can test how the program functions without having to run the installer. So now the file gets put in two places when I only want it in one place. Unless there's a way that I'm missing to tell the installer to put just the executable in a particular folder, it seems that I'm always going to have to have two copies of files if I want to have files installed in directories other than where the executable is.

George

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

[george seifert]

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

Thanks for checking. At least I know I'm not missing something.

So far I'm not seeing any real advantage to the new app builder. Maybe it's great for large projects, but for me it's been a step backward.

George

[JaysonR]

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

Thanks for checking. At least I know I'm not missing something.

So far I'm not seeing any real advantage to the new app builder. Maybe it's great for large projects, but for me it's been a step backward.

George

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.