Re: Correct usage of NSTextView and NSFindBar
Re: Correct usage of NSTextView and NSFindBar
- Subject: Re: Correct usage of NSTextView and NSFindBar
- From: Martin Hewitson <email@hidden>
- Date: Fri, 11 Oct 2013 13:53:17 +0200
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 <email@hidden> wrote:
>
> On Sep 20, 2013, at 10:15 PM, Martin Hewitson <email@hidden> 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 <email@hidden> 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 <email@hidden> wrote:
>>>
>>>>
>>>> On Sep 20, 2013, at 10:00 AM, Martin Hewitson <email@hidden> 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: email@hidden
>> 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: email@hidden
WWW: http://www.aei.mpg.de/~hewitson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden