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
---------------------
jay_reynolds_free...@mac.com
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 (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to