XPost: microsoft.public.vb.general.discussion, microsoft.public.vb   
   From: dsarvas@yahoo.com   
      
   On Sun, 14 Sep 2008 11:09:53 -0700, "Steve Gerrard"   
    wrote:   
      
   >Don wrote:   
   >> On Sun, 14 Sep 2008 12:24:27 -0400, "Jim Mack"    
   >> wrote:   
   >>> I haven't read this whole thread, but in your shoes I would tug at   
   >>> this from the other end. Open the file yourself with exclusive   
   >>> access: lock out all writes except your own.   
   >>   
   >> This was my original plan.  I just wanted to avoid that and find a way   
   >> to detect that Notepad had the file open which I now know can't be   
   >> done.  But . . . (seem my comment following your last comment)   
   >>>   
   >   
   >Like Jim, I haven't read the whole thread. But it occurs to me that the   
   >situation you describe is somewhat unusual. You apparently have text files in   
   >shared locations that more than one user may try to edit at the same time. I   
   >wonder what sort of file that is, and why it is in a shared location.   
      
   As discussed in this thread, putting the files in a non-shared   
   location won't solve the problem.  The problem is that Notepad   
   immediately closes the file after reading in the text so it is no   
   longer open and therefore available for use again even though the file   
   is open on a workstation and can be saved back causing the overwriting   
   condition as described previously.   
   Don   
      
   >Given that there is a reason for it, it is the case that two users could then   
   >"open" (meaning read) the same file using Notepad. User A could then make a   
   >change and save, then user B could make a change and save, over-writing   
   anything   
   >user A did. Since both users have only used Notepad, this has nothing to do   
   with   
   >your app, and everything to do with the decision to put text files in a shared   
   >location that may be simultaneously edited by multiple users using Notepad.   
      
   Same as above as I see it.   
   Don   
      
   >If that functionality is really needed, I would suggest developing a little   
   app   
   >for editing text files that does lock the file during the edit, and   
   distributing   
   >it to the users. Rather than change the registration of .txt files, you can   
   >simply instruct the users that if they want a "safe" text editor that will   
   avoid   
   >collisions, they should explicitly start your text editor program instead of   
   >double-clicking the file.   
      
   That is how my app originally functioned and the purpose of this   
   thread.  Since Notepad is a default on most systems I wanted to take   
   advantage of allowing the user to remain using Notepad, but prevent   
   other users from accessing the file.   
   Don   
      
   >Either that, or make your app treat text files the same way Notepad does -   
   read   
   >them and close, then reopen and overwrite to save changes. That would make it   
   do   
   >the same thing as when two users edit the same file using Notepad, which is   
   >apparently the current situation.   
      
   Again, that's what my app can currently do and that might be how I end   
   up proceeding.  But I'm more inclined to offer the user an option when   
   my app detects that it's a .txt file and give them a choice of Notepad   
   with a warning as previously described, offer a selection of other   
   apps that do keep the file open, or retrieve the file into my app in a   
   Rich Textbox with even more functions than Notepad provides.   
   Don   
      
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)