Re: SciTE and Document Management systems

[Philippe Lhoste]

On 19/11/2012 23:10, Karl_S wrote:
> I am using a Windows PC and we use a document management system to store our files.
> When I open a single file in SciTE all is fine. When I open a second file, the
> document management system wants to bring that file back in as if I have saved or
> otherwise closed the file. I have tried setting both load.on.activate and
> save.on.deactivate to 0 and 1 and the behavior does not seem to change. Assuming this
> is what is happening, is there a way to keep SciTE from making the OS believe the file
> is no longer open?

SciTE tends to lock the directory (-ries?) where it opened a file: one can delete the
currently opened file, but not the folder where it was.
But it doesn't lock files themselves, which is good, IMHO (for technical people, that is).

I suppose your system expects files to be locked, like MS Office does, for example: no way
to move a Word document that is opened.
I wonder if there is some small utility able to do such locking on demand...

--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --

[bfisher]

On Tuesday, November 20, 2012 1:58:53 AM UTC-8, PhiLho wrote:

On 19/11/2012 23:10, Karl_S wrote:
> I am using a Windows PC and we use a document management system to store our files.
> When I open a single file in SciTE all is fine.  When I open a second file, the
> document management system wants to bring that file back in as if I have saved or
> otherwise closed the file.  I have tried setting both load.on.activate and
> save.on.deactivate to 0 and 1 and the behavior does not seem to change.  Assuming this
> is what is happening, is there a way to keep SciTE from making the OS believe the file
> is no longer open?

I haven't debugged something like this for a while, but a possible route of investigation could be to use a WinApi - logging tool like Mark Russinovich's ProcessMonitor. You could collect logs to see what happens when you open the second file. Then you might be able to correlate the document management system's behavior with something SciTE is doing, like a CreateFile/DeleteHandle/LockFile call. I would have thought disabling load.on.activate and save.on.deactivate would resolve this, though.

Out of curiosity, does this happen whenever you change buffers (tabs), or only when opening a new file?

-Ben

[Karl_S]

>
> I haven't debugged something like this for a while, but a possible route of investigation could be to use a WinApi - logging tool like Mark Russinovich's ProcessMonitor. You could collect logs to see what happens when you open the second file. Then you might be able to correlate the document management system's behavior with something SciTE is doing, like a CreateFile/DeleteHandle/LockFile call. I would have thought disabling load.on.activate and save.on.deactivate would resolve this, though.
>
> Out of curiosity, does this happen whenever you change buffers (tabs), or only when opening a new file?
>
> -Ben

So I disabled both load.on.activate and save.on.deactivate, closed SciTE, then opened a file from the document management system. I waited 2 minutes, changed focus to other applications, waited, etc. All was good. I opened a second file from the same location in the document management system and in a couple seconds, I am prompted by the document management system to check the second document in. Both files are in the buffers. Open a third and I get the same.

I am setting these in the global options file, and also commented them out from there and put them in the user options file, setting both equal to 0. I am wondering if the settings are set someplace else. Is there a way to see the current setting of these as opposed to opening all the properties files?

[Karl_S]

Also of note. It appears the second file opens a second instance of SciTE (or attempts to since the document management system is passing a command argument to open the executable) and then that closes. The developer's help desk was of the belief that they are looking for the process to terminate to trigger the prompt to check the file in.

[Patrick Elliott]

That would probably be "no". The whole point of locking a file is to restrict access to the program that locked it, so that updates cannot take place, by someone else, until all such updates have been completed. Having a utility lock the file would, rather than producing the intended result, restrict it to the utility, not Scite. The closest you could get, I suppose, is some sort of proxy, assuming there was some way to do it, scite requests the file from the utility, and that utility read/writes the changes, so you are never actually opening the file itself "in" scite. Needless to say, this is fairly unlikely.

----------------------------------------
> To: scite-i...@googlegroups.com
> From: Phi...@GMX.net
> Subject: [scite] Re: SciTE and Document Management systems
> Date: Tue, 20 Nov 2012 10:58:16 +0100

> --
> You received this message because you are subscribed to the Google Groups "scite-interest" group.
> To post to this group, send email to scite-i...@googlegroups.com.
> To unsubscribe from this group, send email to scite-interes...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scite-interest?hl=en.
>

[Karl_S]

Perhaps I misrepresented what happens. Hopefully this clarifies things:
The document management system (DM) receives a request to open a file. It copies the file from the central location to the local hard drive. It then sends a command to the OS same as a shortcut would, using the appropriate call and any arguments defined in its database for the program associated with the file along with the local file's name and path. So then the target application opens and opens the file. If the DM receives a request for a second file, it does the same, apparently assuming a second instance of the target application will open and stay open. SciTE, however, puts the file in the first instance and closes the second. Since the DM is watching the task, it sees it end and prompts as if the SciTE is dine with the file. I am assuming some of this based on the fact that the first file opened does not prompt but any additional file dies and that the log in the earlier mentioned process monitor shows no action from the DM from the time SciTE starts to open the file until after SciTE stops reporting activity.

[Neil Hodgson]

SciTE does not keep a file open or locked after it has been loaded. Doing so would use additional resources and disallow many common use cases. For example, it is common to use at the same time both a text editor like SciTE and a visual or structural editor on a file.

Neil

[vany...@gmail.com]

Hi,

I have a very annoying problem.
I am editing ftp files mounted in a local folder (SciTE from HG on 64
bit 11.10 Ubuntu). If it happens that the Internet broke then SciTE GUI
become unresponsive. The only think I can do is to xkill SciTE.

Isn't there a solution for this problem?

Thanks
Steve

[Karl_S]

It appears that the document management system is watching the task that was started to open the file.  Commenting out the setting for check.if.already.open and therefore opening 2 windows seems to have resolved this problem.

I like having only 1 window open, so is there a command line argument that can be passed to set check.if.already.open equal to 0?

Karl

On Monday, November 19, 2012 5:10:13 PM UTC-5, Karl_S wrote:

I am using a Windows PC and we use a document management system to store our files.  When I open a single file in SciTE all is fine.  When I open a second file, the document management system wants to bring that file back in as if I have saved or otherwise closed the file.  I have tried setting both load.on.activate and save.on.deactivate to 0 and 1 and the behavior does not seem to change.  Assuming this is what is happening, is there a way to keep SciTE from making the OS believe the file is no longer open?

Karl

[Philippe Lhoste]

On 26/11/2012 19:10, Karl_S wrote:
> It appears that the document management system is watching the task that was started to
> open the file. Commenting out the setting for check.if.already.open and therefore opening
> 2 windows seems to have resolved this problem.
>
> I like having only 1 window open, so is there a command line argument that can be passed
> to set check.if.already.open equal to 0?

-check.if.already.open=0

[Karl_S]

Thank you, Philippe.

As a note for others:

I had tried this prior to my post and it did not work.  Then I switched the order of the arguments after seeing your post and it is working.

This works:

       (scite executable) "-check.if.already.open=0" "%1"

Putting the %1 in front does not work in my case.  So if anyone else comes across this and needs to use it, the order could be important.

Karl

[Neil Hodgson]

vanyinet:

> I have a very annoying problem.
> I am editing ftp files mounted in a local folder (SciTE from HG on 64 bit 11.10 Ubuntu). If it happens that the Internet broke then SciTE GUI become unresponsive. The only think I can do is to xkill SciTE.

It may be possible to allow working on other files when some files are inaccessible by turning on background open and save. Still leaves the 'remote' files in a bad state. Take a look at the background.save.size and background.open.size settings. Background I/O is turned off by default for GTK+ due to reports of failures.

Neil