[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