Re: CGXRemoveTrackingArea problem
Re: CGXRemoveTrackingArea problem
- Subject: Re: CGXRemoveTrackingArea problem
- From: "Louis C. Sacha" <email@hidden>
- Date: Fri, 19 Dec 2003 10:53:52 -0700
Hello...
I'm assuming this is a problem you're finding on 10.3, because it
doesn't seem to happen with my test case under 10.2.6 (although
frequent updates to the tool tip rects seem to prevent the tool tips
from appearing sometimes, due to the rect changing during the initial
delay). Apart from not having a windowserver.log at all, the only
CGXRemoveTrackingArea errors I have in my console log are actually
coming from Project Builder and Interface Builder (with one or two
happening apparently during opening/closing documents). Have you
tried the new 10.3.2 update to see if it might address this issue,
since if it is happening every time you call removeAllToolTips it
seems to be a bug that was introduced in 10.3?
One possibility (although not ideal) would be to set up a single tool
tip rect for each bar that covers the maximum size of the bar, or
possibly all the bars, and use the NSToolTipOwner protocol and
dynamically provide the string based on the point passed to the
view:stringForToolTip:point:userData: method that returns the string
to use. If the point is inside the bar, then you would return the
string, and if not then you would return nil which prevents the tool
tip from appearing. Or, if you use a single rect for all the bars,
return the tool tip for the bar the point is in.
The drawback of this approach is that the mouse usually needs to
leave the defined rect and reenter before the tool tip will be
redisplayed, so if the mouse enters in a part of the rect when the
bar isn't that long but then moves to over the bar without leaving
the rect, the tooltip would not be displayed since you returned nil
the first time because the point wasn't initially in the bar.
Likewise, if you have more than one bar inside the rect, the tool tip
only shows for the first bar you move over, and the mouse needs to
leave the rect before the tool tip would display for another bar.
This may be acceptable to you if you really need the tooltip
functionality, and need to avoid the errors in the window server log
during the time your application is running (except for when you quit
or close the window and the rects are automatically removed...).
The second possiblity is also not an ideal solution, but you could
conditionalize the update of the tool tip rects on whether the mouse
is inside your view using a permanent tracking rect in addition to
your tool tip rects... It would significantly reduce the number of
times you needed to call removeAllToolTips, and as long as the mouse
cursor wasn't sitting inside your view the computer should be able to
sleep.
For example :
In you view class, call addTrackingRect:owner:user
Data:assumeInside:
using your view bounds during initialization or awaking.
Then implement mouseEntered: and set a BOOL flag to indicate that the
tool tip rects need to be updated. The mouseExited: method would
unset that flag.
Then in the method where you update your tool tip rects,
conditionalize it using that flag
if (flag)
{
// remove old tool tips, and replace them using the update rects
}
You could probably reduce the number of updates even further by
deciding on a threshold of how much the bars/graphs needed to change
before you redraw the bars and adjust the tool tip rects. For example
if your bars are showing information using a scale of 1 to100 for
each bar, unless it is critical that your bar graphs be exact, I
don't think anyone would notice if you didn't update the rects if
there was only a difference of 1 or 2 from the last update, although
if some of the values are close and need to line up then it might be
more noticable.
If the text of the tool tips need to change frequently, it would
probably work best if you are using the NSToolTipOwner informal
protocol to provide the strings for the tool tips (if you aren't
already), that way you can always provide the most recent string
without having to reset the tool tip rects just to change the string.
Hope something in there helps...
Louis
On Thu, 4 Dec 2003 08:35:40 -0800, matt neuburg <email@hidden> said:
>My app continuously writes this line to windowserver.log:
Dec 03 11:16:29 [190] kCGErrorIllegalArgument:
>CGXRemoveTrackingArea : Invalid tracking area
Anyone know what I might be doing wrong? I don't even know where
to look.
Just to follow up on this: It turns out that this error line is written to
windowserver.log whenever I call removeAllToolTips or removeToolTip:. I think
this must be a bug in Cocoa.
I was making this call every couple of seconds. This was causing the error
line to be written to windowserver.log every couple of seconds. And this was
causing (1) windowserver.log to become huge, and (2) the computer wouldn't
sleep.
So in the end I just had to give up a significant piece of functionality in my
app (MemoryStick). I no longer have a separate tooltip for each of the four
rectangles in my bar graph.
Probably the reason this bug has never been noticed before is that no one has
ever called removeAllToolTips so often before. m.
--
matt neuburg, phd = email@hidden, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
AppleScript: the Definitive Guide! NOW SHIPPING...! (Finally.)
http://www.amazon.com/exec/obidos/ASIN/0596005571/somethingsbymatt
Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.