View Issue Details

IDProjectCategoryView StatusLast Update
0020185LazarusIDEpublic2014-09-23 21:11
ReporterMartin FriebeAssigned ToPaul Ishenin 
Status closedResolutionfixed 
Product Version0.9.31 (SVN)Product Build 
Target VersionFixed in Version0.9.31 (SVN) 
Summary0020185: W32: IDE Hint trigger it's own hiding (Regression?) =>: Debug hints do not show for some values
DescriptionOn W32:

New application, hover over Form1.

The debugger will actually be asked (the debug output window shows the activity)
But then the hint will not show. Other values work fine.
[tested with the none html version of hints)

This appears to be the case, if the hint text is very big, and the hint window to large (full screen).

A breakpoint in hide hint shows a userinput notification (apparently MouseMove); yet the mouse was *definitely* not moved.
Additional InformationI do remember that such hug hints did work (though it might be their html counterpart)
TagsNo tags attached.
Fixed in Revision35500,35501,35517
Attached Files


related to 0020086 closedPaul Ishenin "Hints" on non-active window are shown 
related to 0024475 closedJuha Manninen Object Inspector contineously flashing vertical line (empty hint) 


Martin Friebe

2011-09-08 02:58

manager   ~0051577

The html hint seems to deal better with this, it shows for large content too

Martin Friebe

2011-09-22 18:06

manager   ~0052113

Windows send MouseMove even if the mouse did not move => that leads to
NotifyUserInput. And that can close the hint window incorrectly

in lcl\interfaces\win32\ line 1768

There is a check comparing the coordinates with the previous location,
But the coordinates are relative to the window,
And they are checked against WindowInfo^ (and that is per window handle)

So if the window below the mouse changed => then this still triggers.

A big hint window for example, can open below the current mouse pos =>
and then it closes immediately again.

       NotifyUserInput := True;
       with LMMouseMove Do
         Msg := LM_MOUSEMOVE;
         XPos := GET_X_LPARAM(LParam);
         YPos := GET_Y_LPARAM(LParam);
         Keys := WParam;
         // check if this is a spurious WM_MOUSEMOVE message, pos not
actually changed
         if (XPos = WindowInfo^.MouseX) and (YPos = WindowInfo^.MouseY) then
           // do not fire message after all (position not changed)
           Msg := LM_NULL;
           NotifyUserInput := false;
         end else
         if WindowInfo <> @DefaultWindowInfo then
           // position changed, update window info
           WindowInfo^.MouseX := XPos;
           WindowInfo^.MouseY := YPos;

Paul Ishenin

2012-02-06 07:30

manager   ~0056558

I was not able to reproduce.

Can you create a small test application?

Paul Ishenin

2012-02-20 07:24

manager   ~0056930

Please test and close if ok.

Martin Friebe

2012-02-20 18:10

manager   ~0056941

Last edited: 2012-02-20 18:19

Well it worked. But with side effect.

Now if the hint opens, with the mouse being over the hint, the mouse can be moved around. The hint does no longer close, until the mouse leaves the hint area.

As long as the assumption, that the hint will never be full screen, is correct, that is easy to overcome. Simply move the mouse off the hint.

(In fact that behaviour might be (optional) wanted, in future, if hint will have click able content)

So it is simply to be decided, if this side effect is wanted.


Also the original problem extended itself (not sure when).
The problem can now also be observed with the HTML hint (TurboPowerIHTmlDsgn package)

And with that, it still occurs.

The sender is now not the hint form, but one of the components on the hint form. "TLazIPHtmlControl"

To make things more complex: Trying to test for this
    and ( (not(Sender is TControl)) or (TControl(Sender).Owner = FHintWindow) )

Sometimes Sender points to an object that was already freed.
That is "Sender <> nil", but (using -gh -gt) the content of sender $f0f0f0f0 ...)

Not yet sure, when and where it got freed.

Paul Ishenin

2012-02-21 01:42

manager   ~0056951

The whole idea with closing hint on every mouse move looks invalid for me. Why accidental mouse moves should close the hint I'm reading? Anyway, this is not a widgetset or LCL issue. Widgetset may send any messages it want and we should not stop that ourself.

I don't know why dead controls are passed there - maybe someone is freeing them in user input handler or a bit before?

Paul Ishenin

2012-02-21 02:08

manager   ~0056952

> and ( (not(Sender is TControl)) or (TControl(Sender).Owner = FHintWindow) )

we can check from the other side :) Please test and close if ok.

Martin Friebe

2012-02-21 17:42

manager   ~0056984


Issue History

Date Modified Username Field Change
2011-09-08 02:34 Martin Friebe New Issue
2011-09-08 02:34 Martin Friebe LazTarget => -
2011-09-08 02:34 Martin Friebe Widgetset => Win32/Win64
2011-09-08 02:58 Martin Friebe Note Added: 0051577
2011-09-08 02:58 Martin Friebe Summary IDE Hint trigger it's own hiding (Regression?) =>: Debug hints do not show for some values => W32: IDE Hint trigger it's own hiding (Regression?) =>: Debug hints do not show for some values
2011-09-22 18:06 Martin Friebe Note Added: 0052113
2011-10-07 10:24 Juha Manninen Relationship added related to 0020086
2011-10-07 15:18 Vincent Snijders LazTarget - => 0.99.0
2011-10-07 15:18 Vincent Snijders Status new => acknowledged
2011-10-07 15:18 Vincent Snijders Target Version => 0.99.0
2011-10-28 11:20 Vincent Snijders Status acknowledged => assigned
2011-10-28 11:20 Vincent Snijders Assigned To => Paul Ishenin
2012-02-06 07:30 Paul Ishenin Note Added: 0056558
2012-02-06 07:30 Paul Ishenin Status assigned => feedback
2012-02-20 07:24 Paul Ishenin Fixed in Revision => 35500,35501
2012-02-20 07:24 Paul Ishenin Status feedback => resolved
2012-02-20 07:24 Paul Ishenin Fixed in Version => 0.9.31 (SVN)
2012-02-20 07:24 Paul Ishenin Resolution open => fixed
2012-02-20 07:24 Paul Ishenin Note Added: 0056930
2012-02-20 18:10 Martin Friebe Status resolved => assigned
2012-02-20 18:10 Martin Friebe Resolution fixed => reopened
2012-02-20 18:10 Martin Friebe Note Added: 0056941
2012-02-20 18:19 Martin Friebe Note Edited: 0056941
2012-02-21 01:42 Paul Ishenin Note Added: 0056951
2012-02-21 02:08 Paul Ishenin Fixed in Revision 35500,35501 => 35500,35501,35517
2012-02-21 02:08 Paul Ishenin Status assigned => resolved
2012-02-21 02:08 Paul Ishenin Resolution reopened => fixed
2012-02-21 02:08 Paul Ishenin Note Added: 0056952
2012-02-21 17:42 Martin Friebe Status resolved => closed
2012-02-21 17:42 Martin Friebe Note Added: 0056984
2014-09-23 21:11 Juha Manninen Relationship added related to 0024475