Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cursor tracking rects

On Saturday, December 29, 2001, at 11:25 AM, email@hidden.
com wrote:

That's what stumped me, then, when I tried to do it. I thought it so obvious that the cursor rects should be calculated once for the whole view, and that the scroll view would automatically clip and compensate for that, that I refused to consider any other alternative :-)

Shouldn't we file a bug on that? Recalculating the rects after every scroll is inefficient and inconsistent with other behavior (for text inside a scroll view).

It isn't really a bug; the assumption of the underlying View subsystem is that a scroll-- or anything else that causes the view to redraw-- can trigger a change in the imaging that will cause the old cursor rects to become invalid. It is left as an exercise for the developer to optimize for the simple case of one text container, one layout manager and one clipped visible rectangle.

While convenience API to handle the simple case would be nice, recalculating the cursor rects after a scroll isn't that inexpensive if the calculations are constrained to the visible range.

A better explanation and/or example of handling cursor rect calculations in the context of a clipview/scrollview combination would be extremely welcome, though (I have file a feature enhancement request for exactly that).

I think it may be that at the time of the first display, the text view isn't fully laid out yet, so calling glyphRangeForBoundingRect will return invalid data. (I ran into this several times when trying to scroll to someplace in the middle). You need to figure out some call to lay out the whole view first, if it isn't already. I forget what I used, but I didn't like it.

-glyphRangeForBoundingRect: will cause the layout manager to generate the glyphs and perform all necessary operations such that it calculates the correct rectangles. There is a second method that is implemented explicitly NOT to cause the additional work to be done, if it hasn't already.

Further analysis reveals that the whole cursor rect calculation stuff isn'
t happening *at all* after the first render. I'm not sure why.

(From Xmanview): I do the following. The -generateManPageDataForQueryString: method takes care of generating all of the attributed text, passing it off to the text view, etc..

[self generateManPageDataForQueryString: queryString];
/* above causes this:
[[manView textStorage] setAttributedString: newString];
[manView scrollPoint: NSMakePoint(0,0)];
[manView setNeedsDisplay: YES];
*/

[[manView window] invalidateCursorRectsForView: manView];

[window makeFirstResponder:manView];

However, the cursor rects are not calculated until the view is either scrolled or resized. I don't know why.

There is also a bug with cursor tracking rects; if the tracking rect is right at the border of the text/scrollview, then the cursor will not always change as the mouse goes over that rect coming from outside the view. If I can figure out a way to generate a fairly minimal example, I'
ll file a bug (I'll probably file one anyway).

b.bum



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.