Call tips extending beyond the bottom of the Scintilla Windows cases an immediate SCN_DWELLEND

[Anders Karlsson]

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.

Cheers
/Karlsson

[Neil Hodgson]

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.

Neil

[Anders Karlsson]

Neil!

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

[Anders Karlsson]

SCN_DWELLEND comes as a result of a WM_MOUSELEAVE message, if that helps.

Cheers
/Karlsson

[Neil Hodgson]

Anders Karlsson:

> 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.

Neil

[Anders Karlsson]

Neil!

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).

/Karlsson

[Neil Hodgson]

Anders Karlsson:

> 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.

Neil

[Anders Karlsson]

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).

/Karlsson

[Neil Hodgson]

Anders Karlsson:

> 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.

Neil

[Anders Karlsson]

Neil!

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

[Neil Hodgson]

   Hi Anders,

 

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

   Neil