Re: Correct usage of NSTextView and NSFindBar
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 0x7fff8a09d41c
__exceptionPreprocess + 172
1 libobjc.A.dylib 0x7fff8d24ce75
objc_exception_throw + 43
2 CoreFoundation 0x7fff8a09d2cc
+[NSException raise:format:] + 204
3 Foundation 0x7fff8a493675 -[NSString
rangeOfString:options:range:locale:] + 186
4 Foundation 0x7fff8a4b3554 -[NSString
rangeOfString:options:range:] + 29
5 AppKit 0x7fff957963c1
_findStringAux + 196
6 AppKit 0x7fff95796636
-[_NSTextFinderImpl rangeOfNextMatchInString:currentRange:forward:wrap:] + 286
7 AppKit 0x7fff95793539
-[_NSTextFinderImpl findForward:completionHandler:] + 1350
8 AppKit 0x7fff954741a2
-[_NSTextFinderImpl _performAction:] + 253
9 AppKit 0x7fff954d53d0
-[NSApplication sendAction:to:from:] + 327
10 AppKit 0x7fff954d524e -[NSControl
sendAction:to:] + 86
11 AppKit 0x7fff9551f7ff
-[NSTextField textDidEndEditing:] + 843
12 CoreFoundation 0x7fff8a06bfcc
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
13 CoreFoundation 0x7fff89f5fc5d
_CFXNotificationPost + 2893
14 Foundation 0x7fff8a4924aa
-[NSNotificationCenter postNotificationName:object:userInfo:] + 68
15 AppKit 0x7fff9551d95d
-[NSTextView(NSPrivate) _giveUpFirstResponder:] + 438
16 AppKit 0x7fff9556ba6c
-[NSTextView(NSKeyBindingCommands) insertNewline:] + 239
17 AppKit 0x7fff954eedaf
-[NSResponder doCommandBySelector:] + 71
18 AppKit 0x7fff9551c23a -[NSTextView
doCommandBySelector:] + 196
19 AppKit 0x7fff954ee2d1
-[NSKeyBindingManager(NSKeyBindingManager_MultiClients)
interpretEventAsCommand:forClient:] + 1392
20 AppKit 0x7fff9550d322
-[NSTextInputContext handleEvent:] + 845
21 AppKit 0x7fff954ecb5d -[NSView
interpretKeyEvents:] + 180
22 AppKit 0x7fff9550cecd -[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
Re: Correct usage of NSTextView and NSFindBar
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
___
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
Re: Correct usage of NSTextView and NSFindBar
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 ___ 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/kperry%40apple.com This email sent to kpe...@apple.com ___ 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
Correct usage of NSTextView and NSFindBar
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. Am I going about this all the wrong way? I thought this is one of those 'it just works' cases Many thanks, Martin ___ 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
Re: Correct usage of NSTextView and NSFindBar
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 ___ 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
Re: Correct usage of NSTextView and NSFindBar
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?
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
___
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
