type def switch in mass compile LabVIEW upgrade

[manliff]

I am looking to upgrade our LabVIEW system from 7.1 to LV 2009.  We keep our code in a set of folders as is convenient for us with shared subvi's.  I have tried two methods to mass compile to code.

Method A) to perform a mass compile on the entire system of folders.  This allows me to not have to load and save all the various top level vi's. 

Method A Problem; on a particular VI, at some subvi that had some type def's the type defs were swapped with some other type def's.  So naturally there were problems with the "Unbundle by name" where the controls didn't match by name of quantity. The two type defs had different names and controls.

My question is how can this happen?

Method B) to peform a mass compile on only the particular Top Level VI.  This compile was successful (except for a mutation one low level vi). The type def's were the right ones.

I am looking for wisdom and or advice regarding our needs and issues.

I am not familiar with the breadth of all the Top Level VI's in all these folders so I would have to carefully search for them.

I will make a speculative guess as to what happens.  The compile process is not actually instantaneous but sequential. So as one shared subvi gets upgraded it become lost to the next subvi that wants to call it, so somehow it calls or somehow substitutes some other vi (or conttol or type def) to replace the missing part.)

So I might guess that the compile needs to be saved to another location entirely.  And I Expect this may apply to either Method A or B.  Well I have something to try. Thanks for your help:)

Thank you,

Manliff K

[Mark_Yedinak]

This can happen if the typedefs had the same name. LabVIEW will use the first one it finds. This has always been an issue and it is known as cross linking. Now that you are upgrading I highly recommend that you start using projects to organize your code. Projects help to alleviate the problems of cross linking and when it does occur will let you know that it is happening so you can resolve the conflict. LabVIEW does not store absolute paths for the VIs that make up an application. It stores the relative paths. Therefore if you are mass compiling and LabVIEW either finds the VI it is looking for in the same relative path it will use that or if it has already been loaded into memory it will use that one. I suspect you are encountering the second case in your mass compile.