Re: Possible hardware-platform-dependent bug in NSTextView?!?
Re: Possible hardware-platform-dependent bug in NSTextView?!?
- Subject: Re: Possible hardware-platform-dependent bug in NSTextView?!?
- From: Jay Reynolds Freeman <email@hidden>
- Date: Fri, 13 Nov 2009 02:20:48 -0800
I seem to have a fix for this one; at least, the person who
originally reported the problem does not see it any more.
But the situation is a little disturbing: On review of my code
I find that perhaps "scrollRangeToVisible" doesn't always do
what its name suggests, at least, not on all Macintoshes.
(I call "scrollRangeToVisible" on the selected range after
each keyDown event has been passed to super, I neglected to
mention that in my original posting about this problem.)
What does seem to work is a follow-up to keyDown that works
like this: (variable declarations omitted to save space)
mainBounds = [self bounds];
theClipView = (NSClipView *)[self superview];
clipViewBounds = [theClipView bounds];
newPoint.x = 0;
newPoint.y = mainBounds.size.height - clipViewBounds.size.height;
if( newPoint.y < 0 )
newPoint.y = 0;
[theClipView scrollToPoint:newPoint];
Why I have to do that I cannot imagine, but it does seem to fix
the problem.
I would like to try to file a bug report on this one, but I am kind
of hampered because the bug does *not* occur on any Mac I own, which
makes it kind of hard to work up and verify a small test case from my
50,000-line application. Any advice? Any folks from Apple
listening?
-- Jay Reynolds Freeman
---------------------
email@hidden
http://web.mac.com/jay_reynolds_freeman (personal web site)
[...]
The bug occurs when a user is typing into an instance of a
subclass of NSTextView that I have created. (Side issue: I
do believe I had good reason to subclass rather than to use a
delegate, details on request.) On some platforms, it appears
that the following happens:
1) When there is more than one line of text in the
instance ...
2) And the insertion point is at the end of the text
(that is, the next ordinary character typed will
become the new last character in the text) ...
3) And the user types a blank-space character, then ...
The view scrolls by one line. The direction of
scroll is that if the insert cursor was 10 cm
up from the bottom of the screen before the 'space',
it will appear at 9.something cm up from the bottom
of the screen after the 'space' has been typed.
That is true whether or not there is any other
text preceding the new 'space', in the last line
of the text.
In my subclass, I did override keyDown, but there is nothing
in my code that treats 'space"' in any special way; that is,
it is *very* mystifying why the display scrolls for 'space'
but does not scroll for, e.g., 'a', 'b', 'c', -- they are all
passed through to [super keyDown:theEvent] without any
variation in treatment in my code.
[...]
The reason this is a problem is that my NSTextView subclass
instance is only one line tall, and the unwanted scrolling
moves the actual insertion point below the bottom of the
view, where the user can't see it.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden