Neil Hodgson wrote:
SetDocumentAt is not really something that should be called from
the tool thread.
This code is within SciTEWin::ExecuteOne(). Maybe I should store the
job output to a variable within the job object and have the
IDM_FINISHEDEXECUTE handler do the replacement.
I
April White:
> Neil, I have alter the code that handles the replacement of the
> selection when a job completes with this code:
> ...
> SetDocumentAt(i);
SetDocumentAt is not really something that should be called from
the tool thread.
> This code is within SciTEWi
Hello Neil.
I guess as I write this it is not 'good morning' but 'good evening'.
Neil Hodgson wrote:
April White:
... revise the code that handles the
"command.replace.selection..." code to locate the original buffer and
select it. ...
... so just make it always switch back.
Nei
Neil Hodgson wrote:
April White:
... revise the code that handles the
"command.replace.selection..." code to locate the original buffer and
select it.
...so just make it always switch back.
I'll add it to my 'todo' list.
... or translate the selection from Canadian.
:-) eh
April White:
> The revisions I have been working on for the new job system is now
> storing the buffer name into the job object, so the 'building' flag can
> be set. It should not be hard to revise the code that handles the
> "command.replace.selection..." code to locate the original buffer and
>
The docs regarding the "command.replace.selection..." property states:
However, please bear in mind that command.replace.selection will
send the output to whatever window is active /when the command completes/.
The revisions I have been working on for the new job system is now
storing the b
