At 04/25/2003 11:41 AM, Jason Teagle wrote:
>You appear to be talking about a live editing session on the file - wouldn't
>it be dangerous to allow it to be edited while someone else has it open and
>might be modifying it? If they make changes after you've opened it, you
>won't see those changes... if you make changes after they've opened it, they
>won't see your changes?
Absolutely, but neither can actually modify the file, because they both
have it open.
>If they have it open read-only, you'd be waiting until they closed it before
>you could save it with any changes... this doesn't seem like a great
>situation for the user, to be denied saving changes until someone else
>relinquishes it? You'd have to go over and tell them to close it otherwise
>you could be there waiting for a long time!
Yes, this is the problem.
But, the current sequence is really ugly when another user has the file open.
Upon save, we make a temp copy of the file, we close the file losing the
changes (but that's OK because we saved the temp copy), we try to delete
the file, this is where the problem happens, and then, if the delete
succeeds, we rename the temp copy to the original filename.
The ugly part is when the delete fails. We have a series of messages boxes
explaining what went wrong. But, then, what do we show the user?
The original file? It looks like the user lost his changes.
The temp file? That shows the changes, but the file reference pointer now
points to the temp file, not the original file. This is a huge error,
because saving the drawing now saves a pointer to a local temp file.
What we do now is show an empty frame where the file contents were. Some
users get really upset, but they did get error message boxes telling them
how to recover the temp file.
Knowing that the file is open by another user would be extremely helpful.
BTW, we have a whole file locking mechanism that users can choose to
activate. The problem is with users who don't use this.
Also, this has been a problem for more than 5 years. The whole reason it
has reared its ugly head is because of WinXP compatibility issues. You can
"fast switch" between users, and the second user can run the same program
the first user was running. Without file locking turned on, this causes
the problem to be more evident.
_ANY_ program that holds files open, is going to have problems passing the
WinXP logo-compliant tests.
Phil Daley < AutoDesk >
http://personal.monad.net/~p_daley
