Dear Kevin,

I finally managed to find some moments to get back to this issue. So, taking 
your advice I changed my approach so that now my data model has a single 
textstorage per file/document being managed. When the user selects a file in 
the list then I do

[textView.layoutManager replaceTextStorage:fileDocument.textStorage];

This works just as well as the old approach with regards swapping out the 
contents of the textview, but still the textfinder is behaving badly.

I still get the false search results and I often get errors like the one below 
if I first search one document then switch documents with the find bar open.

Additionally, continuing the search (hitting the enter key) after switching 
documents sometimes works and sometimes doesn’t (in the sense that sometimes 
new search results are highlighted and sometimes not) - I can’t figure out the 
chain of events that leads to this behaviour. It may be that this particular 
bad behaviour only happens once I’ve hit one of the exceptions below.

So clearly I’m still doing something wrong with regards swapping my textstorage 
objects in and out of the textview. 

Any further clues you can offer would be gratefully received,

Martin




        0   CoreFoundation                      0x00007fff8a09d41c 
__exceptionPreprocess + 172
        1   libobjc.A.dylib                     0x00007fff8d24ce75 
objc_exception_throw + 43
        2   CoreFoundation                      0x00007fff8a09d2cc 
+[NSException raise:format:] + 204
        3   Foundation                          0x00007fff8a493675 -[NSString 
rangeOfString:options:range:locale:] + 186
        4   Foundation                          0x00007fff8a4b3554 -[NSString 
rangeOfString:options:range:] + 29
        5   AppKit                              0x00007fff957963c1 
_findStringAux + 196
        6   AppKit                              0x00007fff95796636 
-[_NSTextFinderImpl rangeOfNextMatchInString:currentRange:forward:wrap:] + 286
        7   AppKit                              0x00007fff95793539 
-[_NSTextFinderImpl findForward:completionHandler:] + 1350
        8   AppKit                              0x00007fff954741a2 
-[_NSTextFinderImpl _performAction:] + 253
        9   AppKit                              0x00007fff954d53d0 
-[NSApplication sendAction:to:from:] + 327
        10  AppKit                              0x00007fff954d524e -[NSControl 
sendAction:to:] + 86
        11  AppKit                              0x00007fff9551f7ff 
-[NSTextField textDidEndEditing:] + 843
        12  CoreFoundation                      0x00007fff8a06bfcc 
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
        13  CoreFoundation                      0x00007fff89f5fc5d 
_CFXNotificationPost + 2893
        14  Foundation                          0x00007fff8a4924aa 
-[NSNotificationCenter postNotificationName:object:userInfo:] + 68
        15  AppKit                              0x00007fff9551d95d 
-[NSTextView(NSPrivate) _giveUpFirstResponder:] + 438
        16  AppKit                              0x00007fff9556ba6c 
-[NSTextView(NSKeyBindingCommands) insertNewline:] + 239
        17  AppKit                              0x00007fff954eedaf 
-[NSResponder doCommandBySelector:] + 71
        18  AppKit                              0x00007fff9551c23a -[NSTextView 
doCommandBySelector:] + 196
        19  AppKit                              0x00007fff954ee2d1 
-[NSKeyBindingManager(NSKeyBindingManager_MultiClients) 
interpretEventAsCommand:forClient:] + 1392
        20  AppKit                              0x00007fff9550d322 
-[NSTextInputContext handleEvent:] + 845
        21  AppKit                              0x00007fff954ecb5d -[NSView 
interpretKeyEvents:] + 180
        22  AppKit                              0x00007fff9550cecd -[NSTextView 
keyDown:] + 658





On 23 Sep 2013, at 06:43 pm, Kevin Perry <kpe...@apple.com> wrote:

> 
> On Sep 20, 2013, at 10:15 PM, Martin Hewitson <martin.hewit...@aei.mpg.de> 
> wrote:
> 
>> Actually, I got this wrong. I swap out the textstorage in the textview by 
>> calling setTextView on the textContainer which I get from the textStorage 
>> that belongs to the file instance being edited. This is probably why I'm 
>> bypassing the 'notification' chain. Perhaps I'm going about this 'one editor 
>> for many files' problem the wrong way because looking back at (very) old 
>> code I get the textContainer by doing
>> 
>> - (NSTextContainer*)textContainer
>> {
>>      // An ugly quick hack to return the 'main' text container for this 
>> document
>>      return [[self.textStorage layoutManagers][0] textContainers][0];
>> }
>> 
>> Is there a better way to do all this?
> 
> That seems a little backwards to me.
> 
> NSLayoutManager is really the center of the Cocoa text architecture. It 
> manages the list of NSTextViews, the list of NSTextContainers (those two 
> objects are associated 1-to-1), and the NSTextStorage that will be rendered 
> and laid out between all of the NSTextViews. It sounds like you're assuming 
> there's a 1-to-1 association between NSTextStorage and NSTextContainer 
> objects, which I don't think is true. The NSTextContainer's job is to define 
> the region in which the text should be rendered—it doesn't really have 
> anything to do with the string itself. Thus, instead of doing this to swap 
> out your NSTextStorage:
> 
>       [textView setTextContainer: <the code you have above>];
> 
> … it would make more sense to me to do:
> 
>       [textView.layoutManager replaceTextStorage: newTextStorage];
> 
> Take a look at 
> https://developer.apple.com/library/mac/documentation/TextFonts/Conceptual/CocoaTextArchitecture/TextSystemArchitecture/ArchitectureOverview.html#//apple_ref/doc/uid/TP40009459-CH7-SW1
>  for more in-depth information.
> 
> -KP
> 
>> Many thanks,
>> 
>> Martin
>> 
>> 
>> On Sep 21, 2013, at 06:52 AM, Martin Hewitson <martin.hewit...@aei.mpg.de> 
>> wrote:
>> 
>>> Ah, that's very useful information. I actually maintain multiple 
>>> NSTextStorage instances, one for each file that's being managed, and swap 
>>> those in and out by doing setTextView on the storage instance. So is this 
>>> somehow bypassing the chain of notifications that tells NSTextFinder that 
>>> the string changed? Any way around that?
>>> 
>>> Many thanks,
>>> 
>>> Martin
>>> 
>>> 
>>> 
>>> 
>>> On Sep 20, 2013, at 07:37 PM, Kevin Perry <kpe...@apple.com> wrote:
>>> 
>>>> 
>>>> On Sep 20, 2013, at 10:00 AM, Martin Hewitson <martin.hewit...@aei.mpg.de> 
>>>> wrote:
>>>> 
>>>>> Dear list,
>>>>> 
>>>>> I have an editor app which presents a list of files that can be edited. 
>>>>> Selecting a file displays the text contents in an NSTextView subclass. On 
>>>>> 10.7 and later the app supports using the FindBar. Searching the 
>>>>> currently displayed text works fine the first time the find bar is used. 
>>>>> But if another file is selected (so that the text in the textview 
>>>>> changes) then the find bar shows nonsensical results, as if subsequent 
>>>>> uses are still looking at the contents of the file that where displayed 
>>>>> when the find bar was first invoked. 
>>>>> 
>>>>> Is there something I can/should do to 'reset' the find bar when the file 
>>>>> being edited changes? I couldn't find anything in the documentation, and 
>>>>> I couldn't figure out how to get the NSTextFinder instance that the 
>>>>> textview is using, and even if I could, I don't see anything in the 
>>>>> documentation to 'reset' its state, or set the string it should search. 
>>>> 
>>>> How are you replacing the NSTextView contents when switching files? The 
>>>> 'reset' call for NSTextFinder when the client's content changes is 
>>>> -noteClientStringWillChange. NSTextView is supposed to invoke this during 
>>>> -shouldChangeTextInRanges:replacementStrings:. It's also invoked during 
>>>> -[NSLayoutManager setTextStorage:], so when you switch your NSTextView 
>>>> contents, you could load the new file's contents into a new NSTextStorage 
>>>> instance, then invoke [[textStorage layoutManager] 
>>>> replaceTextStorage:newTextStorage].
>>>> 
>>>> -KP
>>>> 
>>>>> Am I going about this all the wrong way? I thought this is one of those 
>>>>> 'it just works' cases....
>>>>> 
>>>>> Many thanks,
>>>>> 
>>>>> Martin
>>>>> 
>>>>> 
>>> 
>>> 
>>> 
>> 
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Martin Hewitson
>> Albert-Einstein-Institut
>> Max-Planck-Institut fuer 
>>   Gravitationsphysik und Universitaet Hannover
>> Callinstr. 38, 30167 Hannover, Germany
>> Tel: +49-511-762-17121, Fax: +49-511-762-5861
>> E-Mail: martin.hewit...@aei.mpg.de
>> WWW: http://www.aei.mpg.de/~hewitson
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> 
>> 
>> 
>> 
> 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Hewitson
Albert-Einstein-Institut
Max-Planck-Institut fuer 
    Gravitationsphysik und Universitaet Hannover
Callinstr. 38, 30167 Hannover, Germany
Tel: +49-511-762-17121, Fax: +49-511-762-5861
E-Mail: martin.hewit...@aei.mpg.de
WWW: http://www.aei.mpg.de/~hewitson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~






_______________________________________________

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

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

Reply via email to