Jump to content

Project always shows unsaved


Recommended Posts

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. :P

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.

Link to comment

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

Link to comment

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.

Link to comment

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?

Link to comment

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.

Link to comment

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.

Link to comment

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?

Link to comment
  • 7 years later...

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:

 

post-949-0-51138900-1459959843.jpg

 

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

 

 

Error when building:

 

post-949-0-25935800-1459959915.jpg

 

post-949-0-32302700-1459959939.jpg

 

Anyone know how to fix this?

Edited by Phillip Brooks
Link to comment

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.

Link to comment

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.

  • Like 2
Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.