I've been using Scintilla s.x for a long time, but I have no decided to move to Scintilla 3.22. I then found that DWELL / calltips work differently. Some investigation shows that if CALLTIP is shown in response to a DWELLSTART notification, and the height of the calltip (I have calltips with multiple lines) extends below the lower part of the scintilla Windows, then Scintilla will send a DWELLEND message immediately after SCI_CALLTIPSHOW has been sent.
Note that it's not the height of the Scintilla Windows that causes this, it's the lower end of the Window. So in some cases, if the calltip is on text at the top of the window, the calltip is shown just fine, whereas if at lower part of the window, it will show and then disappear (as on SCN_DWELLEND I send a SCI_CALLTIPCANCEL).
This sure looks like a bug, and in the previous versions of Scintilla, this worked just fine. But I might be wrong and that I have to do something differently. Also, I haven't yet gotten around to debugging why this happens in Scintilla, I just know it happens.
> Some investigation shows that if CALLTIP is shown in response to a DWELLSTART notification, and the height of the calltip (I have calltips with multiple lines) extends below the lower part of the scintilla Windows, then Scintilla will send a DWELLEND message immediately after SCI_CALLTIPSHOW has been sent.
A common source of dwell end events is a change to the scroll position. You should add tracing to understand what is causing the dwell end.
Thanx for the quick reply and I'll sure check that, but I am reasonably sure this isn't the issue. I see the dwellend happening immediately after SCI_CALLTIPSHOW, but only when the window will not fit the tip text. But I'll see if I can trace this some more in Scintilla itself.
Cheers
/Karlsson
On 9/24/2012 14:40, Neil Hodgson wrote:
>> Some investigation shows that if CALLTIP is shown in response to a DWELLSTART notification, and the height of the calltip (I have calltips with multiple lines) extends below the lower part of the scintilla Windows, then Scintilla will send a DWELLEND message immediately after SCI_CALLTIPSHOW has been sent.
> A common source of dwell end events is a change to the scroll position. You should add tracing to understand what is causing the dwell end.
> Thanx for the quick reply and I'll sure check that, but I am > reasonably sure this isn't the issue. I see the dwellend happening > immediately after SCI_CALLTIPSHOW, but only when the window will not > fit the tip text. But I'll see if I can trace this some more in > Scintilla itself.
> Cheers
> /Karlsson
> On 9/24/2012 14:40, Neil Hodgson wrote:
>> Anders Karlsson:
>>> Some investigation shows that if CALLTIP is shown in response to a >>> DWELLSTART notification, and the height of the calltip (I have >>> calltips with multiple lines) extends below the lower part of the >>> scintilla Windows, then Scintilla will send a DWELLEND message >>> immediately after SCI_CALLTIPSHOW has been sent.
>> A common source of dwell end events is a change to the scroll >> position. You should add tracing to understand what is causing the >> dwell end.
> SCN_DWELLEND comes as a result of a WM_MOUSELEAVE message, if that helps.
That's when its supposed to happen. On possibility is that the mouse is moving into the call tip window and that is causing it to leave the main Scintilla window. Take a close look at the coordinates of the mouse and call tip window.
Yes, that is exactly why this happens, the tooltip window overlaps the editor window, and hence the editor window gets a mousemove (as the mouse is now in the tooltip window). This causes the tooltip window to close, and i yoy keep the caret in the same position, the tooltip window will show and hide repeatedly. Why this didn't happen in previous releases I do not know.
A work-around is to call SCI:CALLTIPSHOW with the position I get in the DWELLSTART message + 1. This doesn't fully solve the problem though, as if the position we are dwelling at is at the far right, the the tooltip window will be aligned further to the left, and hence a MOUSELEAVE message will be sent to the editor window.
Actually, I'm sure I'd like to regard this as a bug partly because ot used to work in previous releases (which is no guarantee that is should work the same in more recent releases, I know) and partly because this is no easy fix. What used to b a simple matter when showing tooltips is now complex (i.e., I need to figure out how far the tooltip extends to the right, and if it's further to the right than will fit on the screen, the I need to position the tooltip to the right of themouse position). To be clear, I think Scintilla is great. Brilliant, actually, and this is a very minor flaw.
Another fix, I guess, would be to ignore DWELLEND and instead use WM_MOUSEMOVE? But the bext would be if the tooltip didn't cause a WM_MOUSELEAVE on a WM_CREATE (which I guess is what is happening here? I have to admit I am on deep water now).
>> SCN_DWELLEND comes as a result of a WM_MOUSELEAVE message, if that helps.
> That's when its supposed to happen. On possibility is that the mouse is moving into the call tip window and that is causing it to leave the main Scintilla window. Take a close look at the coordinates of the mouse and call tip window.
> Actually, I'm sure I'd like to regard this as a bug partly because ot used to work in previous releases (which is no guarantee that is should work the same in more recent releases, I know) and partly because this is no easy fix.
I don't think anything relevant has changed recently. It is likely that having another window open under the mouse has always caused a mouse leave.
You could try an old version and if that behaves differently then binary search to find the modification that changed the behaviour.
I have created a W/O for this behavior which might be useful for someone else who wants to show a larger calltip window, and it's actually quite simple.
What I do is that I ignore the DWELLEND, instead on DWELLSTART, in addition to showing the calltip, I also set a global flag that I am showing a calltip and I get the mouse position (using GetCurrentPos()) in another global. Then I use WM_MOUSEMOVE to cancel the CALLTIP, but before that I check that a calltip is showing and the the mouse position is now different from when the calltip was shown.
For a larger calltip, say with multiple lines (say a description of the keyword), this has the advantage that the mouse can now be moved "inside" that window, which can make the text easier read, and while reading this slightly longer text, this will not disappear until the mouse moves bat to the editor window. I think, for this purpose, this looks and works nicer (but probably not do when used as simple CALLTIP providing, say, function arguments).
>> Actually, I'm sure I'd like to regard this as a bug partly because ot used to work in previous releases (which is no guarantee that is should work the same in more recent releases, I know) and partly because this is no easy fix.
> I don't think anything relevant has changed recently. It is likely that having another window open under the mouse has always caused a mouse leave.
> You could try an old version and if that behaves differently then binary search to find the modification that changed the behaviour.
> What I do is that I ignore the DWELLEND, instead on DWELLSTART, in addition to showing the calltip, I also set a global flag that I am showing a calltip and I get the mouse position (using GetCurrentPos()) in another global. Then I use WM_MOUSEMOVE to cancel the CALLTIP, but before that I check that a calltip is showing and the the mouse position is now different from when the calltip was shown.
WM_MOUSEMOVE is a sampled event and there is no guarantee that you will see any WM_MOUSEMOVE messages. That is why mouse leave messages can be useful.
> For a larger calltip, say with multiple lines (say a description of the keyword), this has the advantage that the mouse can now be moved "inside" that window, which can make the text easier read, and while reading this slightly longer text, this will not disappear until the mouse moves bat to the editor window.
Calltips may extend beyond the text window edge so the mouse may be moved outside the whole application without removing the call tip.
Solving this well with a guaranteed dwell end event would be complex.
Thanx for the help on this, I am aware that I am using calltips for something there weren't originally designed for. As for WM_MOUSEMOVE, yes, I understand the implications of using this. Still, WM_MOUSELEAVE / DWELLEND doesn't work here, as the mouse pointer will move "inside" the new (tooltip) window. I'd say that this could possibly be solved by in the code that runs the calltip window itself, so that a DWELLEND is only sent when necessary.
The way I am doing things does seem to work for now it seems, though. I have to admit that my original title for the thread was wrong though, the problem occures when the tooltip window will cover the position of the mouse when dwelling starts.
And yes, using my way of doing this, the tooltip is removed only when the mouse enters the editor window, which looks awkward. I don't see this as a major issue though, it actually works quite well.
If I get the time, I'll debug this in some more detail and provide a smarter solution.
Cheers
/Karlsson
On 9/28/2012 14:02, Neil Hodgson wrote:
>> What I do is that I ignore the DWELLEND, instead on DWELLSTART, in addition to showing the calltip, I also set a global flag that I am showing a calltip and I get the mouse position (using GetCurrentPos()) in another global. Then I use WM_MOUSEMOVE to cancel the CALLTIP, but before that I check that a calltip is showing and the the mouse position is now different from when the calltip was shown.
> WM_MOUSEMOVE is a sampled event and there is no guarantee that you will see any WM_MOUSEMOVE messages. That is why mouse leave messages can be useful.
>> For a larger calltip, say with multiple lines (say a description of the keyword), this has the advantage that the mouse can now be moved "inside" that window, which can make the text easier read, and while reading this slightly longer text, this will not disappear until the mouse moves bat to the editor window.
> Calltips may extend beyond the text window edge so the mouse may be moved outside the whole application without removing the call tip.
> Solving this well with a guaranteed dwell end event would be complex.
If I get the time, I'll debug this in some more detail and provide a smarter solution.
Tried to reproduce this in SciTE but it doesn't occur, so I'm wondering what is happening with you. Here is a SciTE script which also needs dwell to be turned on with, for example, the property setting dwell.period=600
function OnDwellStart(pos, word) if pos > 0 then editor:CallTipShow(pos, "Here is a long calltip and\nthere is a long calltip\nthere is a long calltip\nthere is a long calltip") else editor:CallTipCancel() end end
