[Biococoa-dev] Re: Re : Strange Selection Behavior when using a custom NSTextContainer
Alexander Griekspoor
a.griekspoor at nki.nl
Mon Mar 27 08:03:16 EST 2006
But the problem seems to be in the selection, not in drawing...
Alex
On 27-mrt-2006, at 14:08, Koen van der Drift wrote:
> 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
>>
>> *********************************************************
>>
>
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>
*********************************************************
** 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
*********************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20060327/5152c8d8/attachment.html>
More information about the Biococoa-dev
mailing list