Project always shows unsaved

[Michael Aivaliotis]

I have a project file that always shows an asterisk (like there are unsaved changes) every single time I open it. If I save it, then do a diff on the project file it doesn't show any changes.

What gives?

[Aristos Queue]

QUOTE (Michael_Aivaliotis @ Jan 2 2009, 05:00 PM)

I have a project file that always shows an asterisk (like there are unsaved changes) every single time I open it. If I save it, then do a diff on the project file it doesn't show any changes.

Darn it... I told them to take out the "if (user == Aivaliotis)" code before we shipped.

Seriously though: The only bug like this that I've heard of for projects involves autopopulating folders. X.lvlib owns A.vi. A.vi is saved in a directory which is autopopulated in your project, but the library is not saved in that directory -- it's just a part of the project. So the project loads up, loads the library, then it starts populating the tree, and it includes the VI, and the library says, "Hey! That's mine, you can't have it!" and it tries to go with the VI, but the autopopulating folder says, "You can't come in here! You're not in my directory, Mr. Library!" They have a war which someone eventually wins but in the meantime the poor project gets hit with a docmod.

Autopopulating folders: The only way to win is not to use them.

Of course, this may not be applicable to your problem, Michael. It's the only case I can offer today, though.

[Michael Aivaliotis]

Um, well this is in 8.2.1 so it's probably fixed.

[PaulL]

When autopopulating folders came out I experimented with them and found the same problem described by AQ. I promptly returned to using virtual folders and am glad I did, of course, for many other reasons as well.

I still encounter some mild frustration with projects in 8.6 with respect to saving projects. For instance, with my current project (virtual folders only!) I can save everything, close it, then reopen it only to find an asterisk on the project and a prompt to save it again if I try to close it. Showing the changes only results in the unhelpful message, "An attribute of the project has changed." This has been only a minor annoyance, though, since so far saving the project a second time has resolved the problem. Clearly there is some work for NI to do here. I submitted a request to NI on this.

Paul

[Val Brown]

QUOTE (Paul_at_Lowell @ Jan 5 2009, 09:19 AM)

When autopopulating folders came out I experimented with them and found the same problem described by AQ. I promptly returned to using virtual folders and am glad I did, of course, for many other reasons as well.

I still encounter some mild frustration with projects in 8.6 with respect to saving projects. For instance, with my current project (virtual folders only!) I can save everything, close it, then reopen it only to find an asterisk on the project and a prompt to save it again if I try to close it. Showing the changes only results in the unhelpful message, "An attribute of the project has changed." This has been only a minor annoyance, though, since so far saving the project a second time has resolved the problem. Clearly there is some work for NI to do here. I submitted a request to NI on this.

Paul

I've seen the same behavior in a project that also did NOT have autopopulating folders.

[David Wisti]

I have the same problem here in 8.6. I've always blamed it on the order of dependencies changing in my project. Every time I do a text based compare of the old and new lvproj file this item is always in a different place:

<Item Name="semaphor" Type="VI" URL="semaphor"/>

I do not have autopopulating folders either. Why do dependencies get saved in the lvproj file? Is there any way to turn of saving of dependencies in the lvproj file?

[jzoller]

QUOTE (Michael_Aivaliotis @ Jan 2 2009, 04:00 PM)

I have a project file that always shows an asterisk (like there are unsaved changes) every single time I open it. If I save it, then do a diff on the project file it doesn't show any changes.

What gives?

Same problem here. In my experience, it usually starts occurring after LV crashes (irreproducibly) while the project is open.

Joe Z.

[xtal]

Yes, I see the same thing with one of my main projects after upgrading from 8.2.1 to 8.6. Always an asterisk on it. I don't use auto-populating folders but LV 8.6 has crashed on me a number of times.

[Aristos Queue]

Have any of you filed a bug report? If not, please do so with VIs/lvproj files attached that reproduce the bug.

[Michael Aivaliotis]

Well I'm not using auto-populating folders but I'm using LV8.2.1 which doesn't have this feature BTW.

[xtal]

QUOTE (Aristos Queue @ Jan 6 2009, 06:46 PM)

Have any of you filed a bug report? If not, please do so with VIs/lvproj files attached that reproduce the bug.

Originally I went through hoops with Tech Support for weeks to get things hacked enough to run and my recent crashes aren't reproducible other than they always occur in tagger.exe.

[hooovahh]

I've been working in 8.6 for a little while and I notice something similar. I will open the project and immediately it states that there are changes (the asterisk) If I perform a save all it goes away. One time I clicked the "List Unsaved Changes" and it states that some attributes were changed in the project.

Out of curiosity what does LabVIEW state is the changes in your project?

[David Wisti]

QUOTE (hooovahh @ Jan 8 2009, 11:44 AM)

Out of curiosity what does LabVIEW state is the changes in your project?

An attribute of the project was changed.

[Phillip Brooks]

So,

 

Seven years later, I have a project in LV2014 that has been fine for months and it suddenly starts giving me a 'dirty-dot' on open and the same cryptic message "An attribute of the project was changed." when closing:

 

I also can't create an executable:

 

 

But the code runs fine from the development environment. I created a new project file and it has the same problem.

 

 

Error when building:

 

 

 

Anyone know how to fix this?

Edited April 6, 2016 by Phillip Brooks

[hooovahh]

I saw those kinds of errors at one point, here is a thread that discusses what might be your issue.

 

http://forums.ni.com/t5/LabVIEW/Build-application-still-fails-with-error-1-in-LV12/td-p/2279948

 

Here's another thread that might help too.

 

http://forums.ni.com/t5/LabVIEW/Error-1-when-building-my-application-in-Labview-2010-Version-10/td-p/1515860

 

Basically I think it has an issue with the output folder.  If you make the output path, a new path that doesn't exist (or possibly a new empty folder) that is somewhere near the root of the drive (like C:\Test) I think it may resolve some issues with Error 1, but maybe not your exact situation.

 

I've also had builds fail due to access issues, where maybe an explorer window was already open on the output path.  In these cases I made a Pre-Build VI that would rename the folder if it already existed.  I think that was a different error but could be a similar issue.

 

http://forums.ni.com/t5/LabVIEW/BUG-Application-Builder-fails-if-the-target-window-is-open/td-p/3199387 

 

Historically application builder has been a crap shoot.  I've probably had as many successful builds as failed ones throughout the years.  But honestly using that Pre-build (well a modified one combined with this one) and using 2015 I don't think I've had an unsuccessful build yet.

 

EDIT:  Oh and maybe recreating the project is a good idea if it isn't too much work.

[Phillip Brooks]

I found the root cause of the problem.

 

I had an LLB file that contained a VI with an invalid character in the file name. LabVIEW would compile the VIs, but at the end of the compilation process, the files are copied into a folder named for your .exe.

 

The invalid Windows file name could not be created, but the error message never contained the name of the file. I sent the LLB to NI and declared that I think this is a bug.

 

I found it by converting all of my LLBs to folders using the LLB Manager. When I got to the problem LLB, the conversion reported an error on the badly named file. I copied the LLB, deleted the offending file, converted the copied LLB to a folder without error. I manually saved the offending VI as a file into the folder without an error. Then I could compile.

 

I've had bad experiences in the past when I use "Save As" into an LLB to create a new VI. The "Save As" dialog is not a standard dialog and can act wierd when you use the control keys to move about within the name box. I might have somehow inserted a TAB or control character that LabVIEW was willing to accept as a VI name inside an LLB. LabVIEW just didn't know how to fix the name when saving it outside the LLB. 

 

I spent over a week screwing around with creating new projects, mass compiling and re-installing LabVIEW because of this.

 

I know that many people will say "don't use LLBs", but this is the first time I have been bit by them in such a bad way.

[hooovahh]

I'm not one that uses LLBs, so I'm glad I won't likely see this issue in this way, but regardless of how often I'm going to encounter a bug, I'm glad the cause of a bug was found.  It had not occurred to me that LabVIEW might have different rules for saving files in an LLB than in the OS.  Thank you.