unsaved changes

[MikeBowen]

I am running into a problem with an instrument class showing unsaved changes.  The class is bundled in a Labview project.  Every time I open it I get the "dirty dot" indicating I have unsaved changes.  The class involved using the Labview report writer VI's.  I'm going under the assumption that one or more of the VI's are configured with the "Separate Compiled code from source file" property checked.  The class structure is under source control, but not all of the main labview vi's are (only those that need it are in source code control).  I downloaded a vi (SeparteCompiledCode.lib) that programmatically configures this property, but there are still quite a number of VI's that are listed under dependencies.  Is there another reason this could occur?  Are there any other suggestions for figuring this out?

Mike

[0utlaw]

Hello Mike,

When you see this dialog, select the "List unsaved changes..." hyperlink towards the top of the window.  This should give you an itemized list of what's been changed.  It's often the case that something was recompiled or that dependencies have been loaded from new paths.

Regards,

[MikeBowen]

I do and it says "An attribute of the project was changed."

[0utlaw]

That sounds like a dependency remap or similar.  One thing that may cause that to happen is if you have a mix of virtual and auto-populating folders with shared dependencies or inheritances in the project.  I'd try saving the project with a different name and doing a text diff on them- it may just be that something's linked in a different order. 

Regards,

[MikeBowen]

I don't have any folders defined as auto-populating.  I'm supposed to have one virtual folder that houses the wrapper VIs, but it's not there.  I jsut looked for the wrappers and they are not dfined as part of the project, which is weird.  Will try adding that and see what it does.

I know how to diff a vi for differencees, but not on a project level.  Please explain.

[0utlaw]

Ah, of course!

The project is an elaborate XML document with a specific extension.  You should be able to open it in an advanced text editor that supports comparison and diff them to see what precisely has changed.

Changing dependencies (such as the wrappers you indicated were missing) sounds like it could also cause this- the functions should still be included under the project dependencies, try explicitly including them by moving them up to a target in the project .  It sounds like you may already be in the process of doing this.

Out of curiosity- is the issue just that the project is flagged as having changed?  Is this causing issues with your source code control?

Regards,

[JÞB]

Funny thing about projects and source code control.  MyProject.Aliases unversion and Ignore the *.aliases file and you should be alright.  Otherwise any time your project targets "My Computer" and My Computer (the alias for your computer's IP address) changes the project will get a dirty dot.

Hey, How do some of the rest of you deal with that? I never thought to ask.

[MikeBowen]

That is a good question.  I am using a software pacakage that runs on top of Labview called IVVIVI, which is put out by Cal-bay systems.  What I am running into is when I run a specific module in debug mode (which allows debugging using the standard labview tools) it runs fine, but when running in normal mode (uses the runtime engine) the software flags the module as being broken.  This typically means that there are unsaved changes somewhere in the module or in the instrument drivers.  The instrument driver consists of a project, which houses the classes.  In this case I am creating a printer driver so I can print repair tickets.  The class hierarchy is Labview -> Instrument (not located in the project for a specific instrument class) ->(Printer Project)  Printer Class -> Narrow Width Paper.  What the calling module uses is a driver VI, which in turn calls wrapper vis, which in turn calls the specific instrument (in this case a printer name as defined through windows, or a simulated printer which writes to a text file).  When I open the printer project it shows I have unsaved changes. 

I'm going on the suspicion that one or more of the labview files is configured with the check box checked, which throws it off when compiling.

I was ready to quit when I left on Monday after a 9+ hour day, and I'm apporaching that point again.   Any suggestions?  Other than tossing the laptop in the nearest pond?