Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1545 SCI_SETCURRENTPOS not synchronous with SCI_SCROLLCARET?

Bug
closed
Neil Hodgson
scintilla (169)
5
2013-12-12
2013-11-06
Eric Promislow
No

Komodo bug http://bugs.activestate.com/show_bug.cgi?id=98866
which we keep trying to fix with setTimeouts -- here's what's
going on:

When the user jumps to another <line, col=""> in another file, we essentially
make these calls:

SCI_GOTOLINE(lineNo - 1)
SCI_SETANCHOR(anchor)
SCI_SETCURRENTPOS(currentPos)
SCI_SCROLLCARET()

It turns out that on Windows we need to put the call to
SCROLLCARET in a setTimeout, or, even better, delay it
until scintilla does a NotifyUpdateUI (most likely called
from Editor::IdleWork()). Otherwise, you have to press an
arrow key to get the editor to move near currentPos (or the
selection). Otherwise, the scrollY of the buffer is random.

I believe this is new with version 3.3.3 -- our previous version was
3.2.4, which didn't have this problem.

I suspect this is due to some kind of optimization. When trying to
load buffers I noticed that sometimes the first call to GetTextRectangle
in Editor::XYScrollToMakeVisible (what SCI_SCROLLCARET invokes) sometimes
returned an invalid rectangle, usually a 0 x 0 rectangle. After the
setTimeout, it had non-zero dimensions.

Is this a bug in Scintilla, or deliberate behavior? It happens only
on Windows, not OSX or Linux.

Discussion

  • Neil Hodgson
    Neil Hodgson
    2013-11-06

    Its likely that Komodo or its environment has not (completely) shown or set the size of Scintilla's window when the calls are being made. I can't recall any changes to Scintilla's behaviour in this area. Between 3.2.4 and 3.3.3, there were some changes made in the Windows platform layer for Direct2D/DirectWrite but I don't expect you are using Direct2D.
    Placing traces on WM_SIZE and WM_SHOWWINDOW (or just on all messages) should allow determining the sequence of operations. Sometimes windows showing/sizing/movements are batched up using BeginDeferWindowPos/EndDeferWindowPos or delayed using ShowWindowAsync. If you (or the Mozilla runtime) are using deferred or asynchronous window operations it will impact behaviour strongly so you should determine if this is happening.

     
  • Neil Hodgson
    Neil Hodgson
    2013-12-12

    • labels: --> scintilla
    • status: open --> closed
    • assigned_to: Neil Hodgson