Hi Bruce.
Bruce Dodson wrote:
I wonder if a simpler solution for command.replace.selection might be to
cancel the job (or at least skip the replace-selection part) if the user
changes to another buffer before it completes.
Unless I am wrong, one strong advantage of moving the selection
replacement code from within SciTE::ExecuteOne() to the
IDM_FINISHEDEXECUTE handler is that it moves an buffer update from
within the tool thread back into the UI thread. At least I think the
IDM_FINISHEDEXECUTE handler is in the UI thread.
April
"April White" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
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.
...
It works but the output pane has the contents redraw & repositioned (the
output is longer than the screen, the scroll bar jumps from top to bottom)
several times, at least once in a different font/color. When it is
finished being jittery, the job output is replaced in the buffer I expect
it to and the buffer I had selected was made active again, and the output
pane has the results I expected.
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.
Can you see anything wrong with the above code, and what are your thoughts
on the latter idea.
--
If you are too open minded, your brains will fall out.
_______________________________________________
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
