Sorry to come late to this discussion...

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.

After all, this is dealing with an exception case, and I think skipping the 
replacement would be no less surprising / troubling for the user than the 
other ways of dealing with it.

Bruce



"April White" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> 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.
>
> Neil, I have alter the code that handles the replacement of the selection 
> when a job completes with this code:
>
>            if (doRepSel) {
>
>                int currentBuffer = buffers.Current();
>                FilePath jobBufferPath = jobQueue.CurrentJobBufferPath();
>
>                if (jobBufferPath.IsSet() && 
> !CurrentBuffer()->SameNameAs(jobBufferPath)) {
>                    for (int i = 0; (i < buffers.length); i++) {
>                        if (buffers.buffers[i].SameNameAs(jobBufferPath)) {
>                            SetDocumentAt(i);
> 
> Platform::SendScintilla(wEditor.GetID(),SCI_REPLACESEL,0,(sptr_t)(repSelBuf.c_str()));
>                            SetDocumentAt(currentBuffer);
>                            break;
>                        }
>                    }
>                } else {
> 
> Platform::SendScintilla(wEditor.GetID(),SCI_REPLACESEL,0,(sptr_t)(repSelBuf.c_str()));
>                }
>
>            }
>
> 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.
>
> April
>
> -- 
> Top-of-the-line military hardware, and I'd give anything for a can of 
> Raid.
> Major West, 'Lost in Space' 



_______________________________________________
Scite-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scite-interest

Reply via email to