I have a self modifying typedef that breaks my code

[dacad]

I am a big fan of typedefs, using them wherever I repeat anything or even think I might possibly repeat something.

I have one typedef that I have been using for years and all of the sudden it has begun to modify it's contents for no discernable reason.

The typedef is simply and array of four elements, those elements being an enum with just two options.  Between this week and last week, the typedef suddenly contained six elements and feeding six elements into the vi's that use it causes the vi's to generate errors.  Of course, when it does this, it also causes the constant inputs to those vi's to change to six elements so now I have to go and delete two elements from each constant.

I was working on this yestrday from the top down.  Fixed the tpedef to be four elements, fixed the vi's to be four elements and then systematically going to every instance where there would be a constant input and reducing them to four elements.

This morning, when I opened the project fresh and opened the typedef, it was back to six elements.  It is not strict but I can make it so with no negative effects.  There is nothing written in the code to intentionally modify the typdef programatically.  I have the feeleing that everyone of the fixes I made yesterday are back the way they were and I am going to have to go through al of them again.

Any thoughts on what could be causing this?

[Norbert_B]

Doug,

are several developers working with that typedefs? Are you using source code control?

Could you please verify that these controls are loaded from the same location everytime?

If it was a network drive: is it possible that your IT made a rollback for some reason?

just brainstorming,

Norbert

[CoastalMaineBird]

Never seen anything like this.

Are the enums themselves TypeDefs?  I would typedef the enum with the options "Yes", "No".  Then make the second typedef by an array of four elements, each of the first typedef.  Then MAKE CURRENT VALUE DEFAULT and save that typedef.

Regardless of that, though, if you're sure that your diagram constants are instances of the TYPEDEF, and not copies of the control itself, then I see no reason for what you describe.

Is it possible you are cross-connected?  By that I mean that you open up C:\MyFolder\MyProject\MyCTL.ctl, but the thing is actually linking to C:\MyFolder\MyProject\OLDBACKUPCOPIES\MyCTL.ctl.  So when you reload, it goes to the backup version which is not what you changed.

That's all I can think of.

[JÞB]

Excelant point on the crosslinking.  did opening the project display warnings?  Show file paths in the explorer window(Project>>Show item paths)- are any of them in an odd location?  

[dacad]

The enum elements are not typedefs but the values of the enums are not changing, just the number of elements in the typedef array. There are no other items in the typedef except that array.  Attached just for reference.

There are only two of us working this project and have not done any parallel editing at any point.  No errors in the project related to this issue (one loaction error for a totaly unrelated library but that has been fixed)

The paths shown in the project file are all located under the project folder on the drive. There are also no anomalous dependencies.  I keep the paths shown as I am pretty anal about file locations.  I do not have source control. When I start major edits, I make a backup copy of the entire project to another folder. The original copy maintains the links it is supposed to.

I have never run into this.  Think making it a strict typedef will keep it from happening?  That doesn't fix the root cause but at least I can proceed until I have more time to investigate deeper.

[CoastalMaineBird]

Think making it a strict typedef will keep it from happening? 

I don't know why it would, but I don't understand what's happening exactly.

My rule is to always use STRICT typedefs until and unless I absolutely need to make it non-strict.

[dacad]

I am hoping once I fix EVERY instance of the typdef and the constants feeding in the the vi's, it will not return.  Just in case though I am going to strip the extra elements from any input using the array subset function.  While it may not fix the problem, it will at least fix the symptom.

[CoastalMaineBird]

When I start major edits, I make a backup copy of the entire project to another folder. The original copy maintains the links it is supposed to.

Another thing I do is to make the backups in ZIP format, thus eliminating any possibility of cross linking.

[dacad]

---

CoastalMaineBird wrote:

Another thing I do is to make the backups in ZIP format, thus eliminating any possibility of cross linking.

---

That makes sense.  Will have to layout a plan to implement that.  Would keep the folder structure a bit cleaner as well I suspect.

[CoastalMaineBird]

You should be aware that making a TypeDef, even a STRICT TypeDef, from an array of four elements does not guarantee that any and all instances will have four elements.  The TypeDef is a DEFINITION of data TYPE, but there is NO DIFFERENCE in the data type of a 2-element array of whatsits and a 6 element array of whatsits.  they are perfectly compatible in every respect.

That being said, if you set your TypeDef to have four elements, and MAKE CURRENT VALUE DEFAULT in the typedef, then every constant you create will have four elements to start with, but there's nothing to stop you from accidentally (or otherwise) changing one instance to have five and another to have three, or changing the values of those four on the diagram.

Similarly, every instance of that TypeDef you place on a panel will default to those four values to start with, but there's nothing to keep it that way.

"Having Four Elements" is not a property of any data type.  You can say that the data type is "array of whatsits" but that's it.