I *think* this is the right group, I would be glad to
take it elsewhere if not.
I have reports from users of a problem which seems to be
dependent on the Mac hardware platform my code is running on.
The bug unfortunately does not seem to occur on any Macintosh
that I happen to own, so it is very hard to investigate.
Before I make an appointment to go into the Apple
Compatibility Lab and start fishing, I thought I would ask
for clues and comments here.
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 bug has been reported in both 32-bit and 64-bit versions
of my software (the program "Wraith Scheme") running on in the
following environments:
- An iMac 8,1 running MacOS 10.6.1 and (later) 10.6.2
- A MacBook Pro 5,5, running MacOS 10.6.2
I am quite certain I have not seen it in any version of
Wraith Scheme that I have ever run on any of the following
platforms, which are all the Macintoshes I own:
- Mac Pro 3,1, running 10.6.0, 10.6.1, 10.6.2, and
various 10.5 (both 32- and 64-bit versions of Wraith
Scheme)
- Macbook 13 1,1, running various versions of 10.6,
10.5, and 10.4 (32-bit version of Wraith Scheme
only, that Macbook won't run 64-bit code).
- iBook 4,2 (PowerBook 4,2), running various versions
of 10.4 32-bit version of Wraith Scheme only, that
iBook won't run 64-bit code).
Has anyone seen or heard of anything like this?
I won't be such a fool as to draw conclusions about the
cause of this bug at this stage, but it is at least
logically conceivable that Apple's own software for
NSTextView is doing different things on different
platforms, which is why I thought I would bring the
subject up here.
I will of course report a bug to Apple if it continues
to look like something weird in NSTextView.
Thank you very much.
-- Jay Reynolds Freeman
---------------------
jay_reynolds_free...@mac.com
http://web.mac.com/jay_reynolds_freeman (personal web site)
_______________________________________________
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
