09-28-2009 01:22 PM
LabVIEW 8.6.1f1, Windows Vista Business, WinZIP
My program produces printouts (with an option to save these as PNG files).
It can save them in a folder called "Printouts".
I have an auto-populating folder in my project that links to the PRINTOUTS folder, so I can quickly check on what the image looks like, without wasting paper or time.
I did a print operation, and it produced 4 pages.
I wanted to ZIP these up, and send to my client for approval, as is my custom.
The ZIP operation seems to have proceeded OK, but when I clicked back to LabVIEW, I got the warning shown in the image below.
This is apparently the result of some WinZIP machinations, but my natural inclination was to undo it.
Of course, undoing it is not possible (so why does it offer me the option?), so I had to ACCEPT.
No real harm came of this, as the originals were apparently unchanged, and the ZIP file was intact.
Still, if the choice is between doing something sensible and nagging the user, this is the wrong choice, IMO.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
09-30-2009 01:31 AM
I'm afraid there is very little LabVIEW can do in respect to this. You have read the warning about autopopulating folders and changing anything on the disk without going through the project interface.
Well WinZIP does exactly that. It renames the files it is working on on the fly. The reason is simply. Modifying a ZIP archive is a potentially destructive operation. The state of the archive can get temporarily inconsistent while it is updated with new information and if everything goes fine the operation will update the archive state at the end and all is well. But if some error happens during that operation, the state is undefined and the only way to proceed is to delete the changed file and report failure. So when you tell Winzip to update an archive with new information it renames the old file into a temporary name.
LabVIEW has no way to know that this is caused by WinZIP instead of a notorious user wanting to change the files behind its back. So the choice is not to bother at all with external file changes and run into a real big mess as the state information in the project file gets more and more different to the real situation, or bother each time it notices such a change.
The simple advice is not to use autopopulating folders. They are in many other ways more trouble than good, too.
Rolf Kalbermatter
09-30-2009 09:28 AM
The simple advice is not to use autopopulating folders. They are in many other ways more trouble than good, too.
Blog for (mostly LabVIEW) programmers: Tips And Tricks