LV 7.1.1 and VI version question

[Phillip Brooks]

I recently installed the LabVIEW Version 7.1.1 for Windows 2000/NT/XP -- Patch and have been experimenting with dotNET 2.0.

I first installed the 7.1.1 update, mass-compiled, then installed the 'f2' patch. These installs replaced the original files in my 7.1 installation directory. Everything works fine.

Now....

I'm about to start work on a project with others using LV 7.1 from the original CDs installed.

Does the 7.1.1 version change the VI versions? Would my VIs created in 7.1.1 be compatible with 7.1, or will I need to revert. It's not a problem to revert, I'd just like to save myself the trouble....

[oskarbosch]

Looks like you'll have to revert the VI's back to version 7.1.

Don't think 7.1 can read 7.1.1 version.

Easy check, do file->save with options.

And select save for previous version.

In there you can select version 7.1 (when using labview 7.1.1 of course).

That seems a giveaway that you will have to revert.

Puzzled though why the others in the project can not

run the 7.1.1 patch? Wouldn't that be more stable/robust

than using 7.1??

Oskar

[Phillip Brooks]

Puzzled though why the others in the project can not

run the 7.1.1 patch? Wouldn't that be more stable/robust

than using 7.1??

Oskar

Mostly an administrative issue. I was the one operating 'outside of the box' and I guess I'll have to revert.

Good thing I had a backup of user.lib and instr.lib before the mass compile! :thumbup:

[Jim Kring]

I recently installed the LabVIEW Version 7.1.1 for Windows 2000/NT/XP -- Patch and have been experimenting with dotNET 2.0.

I first installed the 7.1.1 update, mass-compiled, then installed the 'f2' patch. These installs replaced the original files in my 7.1 installation directory. Everything works fine.

Now....

I'm about to start work on a project with others using LV 7.1 from the original CDs installed.

Does the 7.1.1 version change the VI versions? Would my VIs created in 7.1.1 be compatible with 7.1, or will I need to revert. It's not a problem to revert, I'd just like to save myself the trouble....

7.1 and 7.1.1 are compatible. However, they will be re-compiled when moved between these two versions.

[kevintho]

7.1 and 7.1.1 are compatible. However, they will be re-compiled when moved between these two versions.

I'm wondering if it is possible to have an installation of 7.1 and then another installation of 7.1 with the 7.1.1 update patch applied, both available on the same system, (obviously only needing to work in one environment at a time). If it is possible, what are the steps to follow for successfully switching between them?

This question arises out of the need to support multiple clients from the same set of libraries and tools, and hence from the same development computer system; not wanting to add additional efforts of dual boot or virtual PC, etc.

Specifically, I have a client that can't / won't upgrade to the patched version (cost of his test systems being down is too high for that kind of maintenance / updater downtime and risk, especially since it doesn't seem necessary for his needs), and at the same time I'm supporting another client that has updated all of their systems to the 7.1.1 patch. Neither plan to move to version 8, and I need to support both from the same set of my own libraries. Up to this point, I've been just re-saving after re-compiling each time, but that certainly gets to be tedious due to revision control system hassels, etc.

I'd be grateful for any suggestions.

[Chris Davis]

...

This question arises out of the need to support multiple clients from the same set of libraries and tools, and hence from the same development computer system; not wanting to add additional efforts of dual boot or virtual PC, etc.

...

I'd be grateful for any suggestions.

The only suggestion I know that will work, involves Virtual PC.

However, you could try installing LV 7.1 on a new machine, copy the LV 7.1 subdirectory to another location, then install the LV 7.1.1 patch and see if you have what you are looking for. I don't know if that would mess up your user.lib and vi.lib directories (which are what gets changed when applying the patch), but it might be worth trying. I also can't say if this "solution" will work, since I haven't tried it myself. You might want to try this on a spare HD or (even better) a spare computer / virtual PC :laugh:

[kevintho]

The only suggestion I know that will work, involves Virtual PC.

However, you could try installing LV 7.1 on a new machine, copy the LV 7.1 subdirectory to another location, then install the LV 7.1.1 patch and see if you have what you are looking for. I don't know if that would mess up your user.lib and vi.lib directories (which are what gets changed when applying the patch), but it might be worth trying. I also can't say if this "solution" will work, since I haven't tried it myself. You might want to try this on a spare HD or (even better) a spare computer / virtual PC :laugh:

Thanks for the reply. Another idea, along similar lines, was after patching 7.1 on the development system, and then copying LV71 to a unique folder name from another installation, manually manage renaming the top level folders depending on which client I am currently supporting. In other words the folder name would always be for example "..\LabVIEW 71" that I run the development environment from, which would be swapped with folder names "holdLV71" and "holdLV711" as temporary locations. Don't know how well that will work since I am dealing with windows and all the rubbish from the registry. I guess the key is to what degree running the LabVIEW development environment (whether 71 or 711) is dependent on registry entry distinctions between 71 and 711. Should be fun...

I may have to use Virtual PC, but I'll need to determine if the re-saving / revision control system hassels I'm going through now would be offset by the hassels of buying and maintaining another Windows installation via Virtual PC (anti-virus, MS updates, anti-spyware, networking issues, blah, blah, blah puts me in a bad mood just thinking about it :thumbdown: ).

[kevintho]

Thanks for the reply. Another idea, along similar lines, was after patching 7.1 on the development system, and then copying LV71 to a unique folder name from another installation, manually manage renaming the top level folders depending on which client I am currently supporting. In other words the folder name would always be for example "..\LabVIEW 71" that I run the development environment from, which would be swapped with folder names "holdLV71" and "holdLV711" as temporary locations. Don't know how well that will work since I am dealing with windows and all the rubbish from the registry. I guess the key is to what degree running the LabVIEW development environment (whether 71 or 711) is dependent on registry entry distinctions between 71 and 711. Should be fun...

OK.

I thought I would follow up on my results. The above approach works fine, so far. I can easily switch between LV71 and LV711 development environments on the same computer. I simply swap names for the top level folder for LabVIEW.

1. Make a backup copy of the LV71 folder, leaving the original folder (I

[Chris Davis]

Glad to hear that this idea works! It may come in handy in the future.

You might try automating the startup of 7.1 and 7.1.1 using a batch file to script the folder name changes you need to make your solution work.

[LAVA 1.0 Content]

You might try automating the startup of 7.1 and 7.1.1 using a batch file to script the folder name changes you need to make your solution work.

I can't remember if windows uses a path or a registry entry to find the associated program when double clicking a LabVIEW file type, but if you're creating a batch file to rename the directories, then you may want to make sure that the file associations (.vi, .ctl, etc) point to the correct place.

You can add these DOS command lines to your batch file:

FTYPE LabVIEWControl="C:\Program Files\National Instruments\LabVIEW 7.1\LabVIEW.exe" "%1"FTYPE LabVIEWControlTemplate="C:\Program Files\National Instruments\LabVIEW 7.1\LabVIEW.exe" "%1"FTYPE LabVIEWInstrument="C:\Program Files\National Instruments\LabVIEW 7.1\LabVIEW.exe" "%1"FTYPE LabVIEWInstrumentTemplate="C:\Program Files\National Instruments\LabVIEW 7.1\LabVIEW.exe" "%1"FTYPE LabVIEWLibrary="C:\Program Files\National Instruments\LabVIEW 7.1\LabVIEW.exe" "%1"ASSOC .CTL=LabVIEWControlASSOC .CTT=LabVIEWControlTemplateASSOC .llb=LabVIEWLibraryASSOC .vi=LabVIEWInstrumentASSOC .VIT=LabVIEWInstrumentTemplate

To see the current associations for an entry, use the same command without an assignment:

FTYPE LabVIEWControlFTYPE LabVIEWControlTemplateFTYPE LabVIEWInstrumentFTYPE LabVIEWInstrumentTemplateFTYPE LabVIEWLibraryASSOC .CTLASSOC .CTTASSOC .llbASSOC .viASSOC .VIT

Or if you're curious about other associations, just type FTYPE or ASSOC and be prepared to read fast