Since the introduction of the new timers between Scintilla 3.4.4 and 3.5.0, SCI_CALLTIPSHOW and/or SCN_DWELLSTART are broken.
In our application, we display a calltip either when the mouse stayed over a word for a certain amount of time (SCN_DWELLSTART) or when invoked by a shortcut. If the mouse is moved to a position with no word underneath, any active calltip is cancelled.
This worked perfectly fine until 3.4.4. Starting with 3.5.0, if a tooltip is displayed via shortcut, it is cancelled shortly afterwards. We found out that once a calltip is displayed, Scintilla starts to count the dwell time (although the mouse has not moved) and eventually sends the SCN_DWELLSTART notification. As the mouse is at that time over free space, the calltip is cancelled (or another calltip is displayed if the mouse happens to be over another word).
We found out that this new behaviour was introduced with the changeset that re-implemented timers in Scintilla.
I can provide you with a small MFC demo application if needed.
SCI_CALLTIPSHOW doesn't start or stop a timer.
After the calltip is displayed, we see a WM_MOUSEMOVE message in the message queue which eventually triggers the dwell timer. The mouse not been moved in the meanwhile though.
Where might WM_MOUSEMOVE be coming from?
Can't see any reason for the mouse move and this behaviour isn't seen in SciTE.
We could reproduce the bug with SciTE 3.5.1 on Windows:
We configured a dwell time of 333 ms, the action on SCN_DWELLSTART is to cancel the calltip, then we hit Ctrl-Shift-Space which displayed a calltip ... which got cancelled shortly afterwards although the mouse had not been moved.
We observed this same mouse move message after displaying the calltip as seen in our MFC application.
You might want to check the second to last paragraph of this blog post which could explain the mouse move message:
http://blogs.msdn.com/b/oldnewthing/archive/2003/10/01/55108.aspx
In ButtonMoveWithModifiers you could try checking for a real move (pt != ptMouseLast) and only calling FineTickerStart when there is a real mouse move. See if that improves things in your situation.
As the issue is raised by receiving spurious WM_MOUSEMOVE messages, we opted to fix the problem where WM_MOUSEMOVE is handled in ScintillaWin.cxx instead of Editor::ButtonMoveWithModifiers() which contains platform independent code.
ButtonMoveWithModifiers() is also used for implementing autoscrolling, so it is invoked although no WM_MOUSEMOVE message was sent at all.
Please see the attached patch. Credits for finding and fixing the bug go to Yusuf Ramazan Karagöz.
Committed as [fe38be].
Related
Commit: [fe38be]