Custom tool-tips

[Christiaan Hofman]

(Solved)

Thanks Gerd, but that sounds far too involved. It would require finding the
relevant window and view under the mouse; I wouldn't even know how to do
this (I can't find a hitTest method to find the top window ion the public
API, and the -[NSView hitTest:] method should be send to the private root
view of a window, as it seems to me). Also this would come for every
mouseMoved, even ones completely unrelated to my windows. That's a lot of
overhead.

I have found a better solution using tracking rects. The buggy ordering of
the entered/exited events can be worked around by ignoring mouseExited
events that do not match the last mouseEntered event (yes, I consider this a
bug).

I found that the delay of these events was related to a queuing of
mouseEntered/mouseExited (mouseMoved does not seem to be queued), and the
delay was basically due to the drawing of a lot of tool-tips (the problem
arises when moving the mouse fast over a lot of tracking rects). It is
better to drop tool-tips when they come fast behind each other, as the
system does. My idea to do this is to use a timer with a small time
interval. This did not work at first because of a bug in NSTimer (class
methods apparently ignore a sub-second time interval, but the init... method
does not seem to be affected).  But I've got that fixed now.

Christiaan


On 4/19/07, Gerd Knops <gerti at bitart.com> wrote:
>
> I would use a top-down approach:
>
> Subclass NSApplication, specifically
>
>         - (void)sendEvent:(NSEvent *)anEvent
>
>
> This is where all events pass through. Here you can observe
> mouseMoved events. When the proper timing/pause is detected, find the
> window and view the mouse is over, and query the view for your custom
> ToolTip data.
>
> Gerd
>
> On Apr 19, 2007, at 7:06 AM, Christiaan Hofman wrote:
>
> > Hi list,
> >
> > I was wondering if anyone could give me some hint about
> > implementing custom tool-tips for a view myself. I don't just mean
> > supplying a string for a tooltip, that's easy, but custom managing
> > and showing of tool-tips. Reason: my tool-tips are not simply
> > strings, but are more involved (like images). Also due to an Apple
> > bug we had to disable the standard tool-tips.
> >
> > We basically have the code for showing the tool-tip (a custom
> > window subclass with a timer and animation), that works all nicely
> > now.
> >
> > My question is about the event handling: how to catch the relevant
> > events and when to show/hide the tool-tip window.
> >
> > Currently we use -mouseMoved: for that. That basically works, but
> > it has one problem: it is only called when the view is first
> > responder. Normal tool-tips are also shown when a view is not first
> > responder, and I'd like to have that too.
> >
> > I also tried adding tracking rects and implementing -mouseEntered:/
> > Exited:. That has several problems of its own. The most important
> > is that those are often delayed, giving an annoying lagging
> > behavior, and also do not come in a logical order (I often get a
> > sequence like entered-entered-exited-exited, even for non-
> > overlapping rects).
> >
> > I wonder what the normal behavior for tooltips added using -
> > addToolTipRect:owner:userData: does. Is it true that those are
> > handled by the window, rather than the view? And most importantly:
> > what events does the window(?) catch to support tool-tips, and when
> > and how? Is this already in private methods before the event is
> > further dispatched to the view hierarchy? Would it mean that I
> > should subclass the window to simulate the normal tool-tip behavior
> > (and the natural next question: how)?
> >
> > I would appreciate some hints to help me further.
> >
> > Christiaan
> >
> > _______________________________________________
> > MacOSX-dev mailing list
> > MacOSX-dev at omnigroup.com
> > http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
>