[Biococoa-dev] Re: Re : Strange Selection Behavior when using a custom NSTextContainer
Koen van der Drift
kvddrift at earthlink.net
Mon Mar 27 07:08:27 EST 2006
One way to debug this would to be able to draw a rect around the
various NSRects during the calculations. However, AFAICT that can
only be done from within drawView, and I have no clue how to access
these rects from the textContainer (except the container itself).
cheers,
- Koen.
On Mar 27, 2006, at 6:13 AM, Alexander Griekspoor wrote:
> First I thought it was my message which finally arrived on the
> cocoa-dev list, turns out someone else has exactly the same problem
> as we do!
> See the mail below, perhaps it helps solving this nasty bug...
> Alex
>
> Begin forwarded message:
>
>> From: Alexander Griekspoor <a.griekspoor at nki.nl>
>> Date: 27 maart 2006 13:01:32 GMT+02:00
>> To: ernfrid at gmail.com
>> Subject: Re : Strange Selection Behavior when using a custom
>> NSTextContainer
>>
>> Hi David,
>>
>> I have exactly the same problem, well slightly different, but at
>> first I thought your message was mine. I am trying to post the
>> message below to apple's cocoa-dev but it seems they are offline.
>> Here is a copy,
>> perhaps we can together find out what goes wrong... If you have
>> found the solution already I would love to hear. Many thanks!
>> Cheers,
>> Alex
>> PS. I'm not a member of Omni's mailinglist, could you post my
>> message for the record and also for others to help us out?
>>
>>
>> *******
>> Weird bug with selection in Textview with custom textcontainer
>>
>>
>> Hi all,
>>
>> I ran in this weird bug and you guys are my last resort..
>> For a new DNA analysis program I subclassed Koen van der Drift's
>> excellent NSTextView linenumbering variant and modified the
>> textcontainer such that it automagically adds spaces between every
>> 10th character. I did this by overriding in NSTextContainer (see
>> below).
>>
>> This works beautifully except for this single strange behaviour
>> where text is not selected if
>> A) there are more than 10 characters (is one column) present
>> B there's not more than 1 line of text.
>>
>> Trying to select the first 10 characters is not possible and a
>> reverse selection started at for instance char 20 back will stop
>> always at character 11. If the textview does not contain more than
>> 9 characters selection goes fine in the first column! So does it
>> when the textview contains more than one line of text!
>>
>> In other words, I cannot select the 10 characters in the first
>> column for some reason.
>> I've illustrated the problem in this screenshot: http://
>> www.mekentosj.com/temporary/textview_problem.jpg
>>
>> Any solution / clue where to start looking would be enormously
>> appreciated. Last bug standing before a release...
>> Cheers,
>> Alex
>>
>> - (NSRect)lineFragmentRectForProposedRect:(NSRect)proposedRect
>> sweepDirection:(NSLineSweepDirection)sweepDirection
>> movementDirection:(NSLineMovementDirection)movementDirection
>> remainingRect:(NSRect *)remainingRect
>> {
>> // create space for the linenumber margin
>> if(proposedRect.origin.x <= 0.0)
>> proposedRect.origin.x = kLEFT_MARGIN_WIDTH;
>>
>> // set the width of a column of text
>> proposedRect.size.width = columnWidth;
>>
>> // make sure we nicely break after a full column
>> if (proposedRect.origin.x + 2 * columnWidth - 20.0 >= [self
>> containerSize].width) *remainingRect = NSZeroRect;
>> else {
>> remainingRect->origin.x = proposedRect.origin.x +
>> columnWidth - 10.0;
>> remainingRect->origin.y = proposedRect.origin.y;
>> remainingRect->size.width = [self containerSize].width -
>> proposedRect.origin.x + columnWidth - 10.0;
>> remainingRect->size.height = proposedRect.size.height;
>> }
>>
>> return proposedRect;
>> }
>>
>>
>>
>>
>>
>> I'm using a custom NSTextContainer which breaks each line of the text
>> view into columns of ten characters. I noticed that when there is
>> only
>> one line in the container, but there is text displayed outside of the
>> first column, clicking in the that first column moves the cursor to
>> the beginning of the second column instead of to its appropriate
>> insertion point in the first column. I can move the cursor using the
>> arrow keys into the first column, but even if the cursor is in the
>> first column, clicking on that column sends the cursor back to
>> beginning of the second column. If, however, there is only text in
>> the
>> first column or there is more than one line, clicking in the first
>> column results in normal positioning of the cursor. I'm stumped. I
>> played around with overriding containsPoint: and clicks in the first
>> column were returned as being part of the container as they should
>> be.
>> I also used a subclass of NSTextView to check what NSTextView was
>> returning for the selection function and found it was returning the
>> incorrect insertion point. If I comment out my
>> lineFragmentRectForProposedRect function then there is no problem
>> with
>> moving the cursor back to the first ten characters with the mouse. I
>> should also mention I set the line fragment padding to zero and
>> changing this has no effect on this behavior. Here is the code I'm
>> using. columnWidth is the length of each column and gapWidth is the
>> space between each column. Anyone have any ideas about what I'm doing
>> wrong? I apologize for the long post but I believe it was necessary.
>>
>> Thanks
>>
>> David Larson
>>
>> - (NSRect)lineFragmentRectForProposedRect:(NSRect)proposedRect
>> sweepDirection:(NSLineSweepDirection)sweepDirection
>> movementDirection:(NSLineMovementDirection)movementDirection
>> remainingRect:(NSRect *)remainingRect
>> {
>> if((sweepDirection != NSLineSweepRight) ||( movementDirection !=
>> NSLineMovesDown)) {
>> //check to make sure standard linesweep and movement direction
>> are correct
>> return NSZeroRect;
>> }
>> else {
>> //this code grabbed off of the CocoaBuilder webarchives from a
>> Marco
>> Binder post. Minor modifications to include gap size were included
>> //Also modified the code to force a new line when the edge of the
>> container is reached
>> //Comments are mine
>>
>> //set the width to the column width
>> //note that this assumes that the rect starts at the beginning
>> of a column
>>
>> proposedRect.size.width = columnWidth;
>>
>> if (proposedRect.origin.x+columnWidth >= [self
>> containerSize].width) {
>> proposedRect.origin.x = 0; //if we can't fit the complete rect
>> into
>> the rest of the line, reset the line manually
>> proposedRect.origin.y += proposedRect.size.height;
>> }
>>
>> remainingRect->origin.x =
>> proposedRect.origin.x+columnWidth+gapWidth; //move remaining rect
>> origin to the next column start
>> remainingRect->origin.y = proposedRect.origin.y;
>> remainingRect->size.width = [self containerSize].width -
>> proposedRect.origin.x - columnWidth-gapWidth; //size equals remaining
>> screen space minus the column and gap
>> remainingRect->size.height = proposedRect.size.height;
>> }
>>
>> return proposedRect;
>> }
>>
>> ***********************************
>> Mek (Alexander Griekspoor)
>> MekenTosj.com
>> Web: http://www.mekentosj.com
>> Mail: mek at mekentosj.com
>> ***********************************
>>
>>
>
> *********************************************************
> ** Alexander Griekspoor **
> *********************************************************
> The Netherlands Cancer Institute
> Department of Tumorbiology (H4)
> Plesmanlaan 121, 1066 CX, Amsterdam
> Tel: + 31 20 - 512 2023
> Fax: + 31 20 - 512 2029
> AIM: mekentosj at mac.com
> E-mail: a.griekspoor at nki.nl
> Web: http://www.mekentosj.com
>
> Claiming that the Macintosh is inferior to Windows
> because most people use Windows, is like saying
> that all other restaurants serve food that is
> inferior to McDonalds
>
> *********************************************************
>
More information about the Biococoa-dev
mailing list