unespected behavior of some NSWindow, NSView methods
unespected behavior of some NSWindow, NSView methods
- Subject: unespected behavior of some NSWindow, NSView methods
- From: Andrea Perego <email@hidden>
- Date: Wed, 12 Dec 2001 16:54:10 +0100
Dear fellow developers,
I'd like to tell you about a couple of strange thing that I found
while playing with NSWindow and NSView:
A- NSWiew's
- (NSTrackingRectTag)addTrackingRect:(NSRect)aRect owner:(id)anObject
userData:(void *)userData assumeInside:(BOOL)flag
I've set up a tracking rect to do some things when the mouse enters
my custom view and its window is the main window. In some cases the
mouse is already within the view when the rect is created (e.g. if
you send a window to the dock, then click its icon and move the mouse
to a point within the region previously occupied by the window,
preceding the "genie" effect). By reading the method info:
" flag determines which event is sent first by indicating where the
mouse is assumed to be at the time this method is invoked. If flag is
YES, the first event will be generated when the mouse leaves aRect;
if flag is NO the first event will be generated when the mouse enters
it. "
I guessed I had to pass "assumeInside: YES" in those cases.
Well, doing so seems to cause a very strange behavior; namely
- you move the mouse outside and "mouseExited" is sent (OK!)
- you move the mouse inside: no "mouseEntered" (???)
- you move the mouse outside and and "mouseExited" is sent again
from now on, everything works as one would expect.
Two consecutive "mouseExited" events are very puzzling, IMHO; I've tested
that, perchance, I hadn't *two* track rects instead of just one, by
checking the rect tag.
Pragmatically, I've changed the code to issue always "assumeInside:
NO" and everything seems to work fine, but I'd like to know where I
was wrong in my previous conception.
B- NSWindow's
- (void)cacheImageInRect:(NSRect)aRect
- (void)restoreCachedImage
- (void)discardCachedImage
My purpose here is to draw a cross-hair centered on the mouse
position and stretching to the borders of the view, updating it to
follow the mouse movement.
From the documentation of the methods above, one would guess that it
is possible to cache more that a single rect; e.g.
Info on "restoreCacheImage" says
" Splices the receiver's cached image rectangles, if any, back into
its raster image..."
while for "discardCacheImage" it is written
" Discards all of the receiver's cached image rectangles. "
So, one might code the dynamical drawing routine within "mouseMoved"
as something like:
[myWindow restoreCachedImage]; // restore image at previous cross-hair position
.......
[myWindow cacheImageInRect:rect1]; // cache image where hor. line of
cross-hair will be
drawn
[myWindow cacheImageInRect:rect2]; // ditto for vertical line
...... draw cross-hair ......
But, in my own code, only the last-cached rectangle is restored.
Of course, a rectangle that encompassed the cross-hair would have to
be exactly as big
as [myView bounds], and caching such a big piece of real estate,
besides being inelegant,
seems to affect performance, at least on an iMac.
Therefore I'd deeply appreciate to be informed if someone of you was
able to use the caching mechanism with more rects, or knows for sure
that it is impossible.
--------------------
To the heroes at apple that are working hard to upgrade cocoa docs (I
know some of you
are reading ;-> ):
I hadn't time enough to form a precise opinion on the new December
version, but from what
I've seen while looking for the issues above, it seems to me that
contents might be better linked together when the explanation
material for a class (as NSWindow) has been removed and set apart
from the reference sheet where methods are listed. I mean, a link to
the explanation might be put in the header of the ref., while the
names of methods in the explanatory document might be linked to the
correspondent places in the reference part.
Please consider this just a suggestion, not a critic! I'm aware of
the hard time you have
with your work.
Best Regards
Andrea Perego
Universtity of Florence - Phys. Dept.