Re: Getting at NSTextFinder from text view
On 14 Apr 2015, at 13:30, Shane Stanley sstan...@myriad-com.com.au wrote: On 14 Apr 2015, at 9:19 pm, Martin Hewitson martin.hewit...@aei.mpg.de wrote: But if it fails for the first subsequent search, then the crashes will still happen if the old search results are out of range of the new string. Right? No, there's no crash -- and it doesn't fail. In fact, the odd behavior I was alluding to actually seems to be a normal inconsistency in the find bar's behavior. Hmm, are you sure about this? I was just able to produce one. In my first text storage I have a long string and search for a common word like “the”. Then I switch to the second text storage which has a much shorter string and: 2015-04-14 14:04:07.719 An uncaught exception was raised 2015-04-14 14:04:07.719 *** NSRunStorage, _NSBlockNumberForIndex(): index (1560) beyond array bounds (452) :( -- Shane Stanley sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ ___ 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/martin.hewitson%40aei.mpg.de This email sent to martin.hewit...@aei.mpg.de ___ 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: Getting at NSTextFinder from text view
On 14 Apr 2015, at 10:05 pm, Martin Hewitson martin.hewit...@aei.mpg.de wrote: Hmm, are you sure about this? I was just able to produce one. In my first text storage I have a long string and search for a common word like “the”. Then I switch to the second text storage which has a much shorter string and: This is what I'm doing in my text view subclass: [self setIncrementalSearchingEnabled:NO]; [self.textFinder noteClientStringWillChange]; // modify textStorage here [self setIncrementalSearchingEnabled:YES]; Seems to be working in my (admittedly limited) testing. -- Shane Stanley sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ ___ 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: Getting at NSTextFinder from text view
I’m afraid I may not be too helpful here because in my case I’m not using an NSTextView, rather mine is a custom view that displays text in various ‘cells’ so I had to implement the full textFinderClient protocol and build a corpus of searchable text for it to query against. On 14 Apr 2015, at 07:20, Martin Hewitson martin.hewit...@aei.mpg.de wrote: Alas, this doesn’t actually help. If I do this, then switch out the text storage, then the very next time the user hits cmd-f the old search results are highlighted again, but of course over the wrong text, and potentially out of range. My impression is that the -cancelFindIndicator doesn’t clear the last search, just removes it from the screen. Then when bringing back the find bar (after a cancel) the old results are assumed still to be ok, rather than being recalculated. At this point you need to re-cache the data the find bar is using. In my case, because I’m implementing the NSTextFinderClient protocol, I simply rebuild the model that is the store of text to search (an array of dictionaries as it happens). When the text finder asks for its data it is thus correct and up to date. It would seem that in both your cases NSTextView should be fully aware of all this by itself. Perhaps the problem is in switching the NSTextStorage out without notifying the text view of the change? Are you swapping the textStorage instance completely? Perhaps changing it’s content and wrapping with editing calls would work? : [textStorage beginEditing]; [textStorage setAttributedString:theNewAttributedString]; [textStorage endEditing]; Maybe there’s another way to inform the parent textView that it’s content has been changed. Shane, in your case I agree, -noteClientStringWillChange sounds like exactly the method that’s needed. I can’t see how to get to the textView’s textFinder either. You can get to the *findBar* with [[self.textView enclosingScrollView] findBarView] but that’s just an NSView and likely to not be helpful. If you’re not creating your own textFinder (and it seems from Martin’s experience that even if you do it doesn’t work) then the only thing I can think of is to somehow notify the textView that its content has changed and hope and presume that it has an internal mechanism for also notifying its textFinder. Sorry I can’t be more helpful. ___ 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: Getting at NSTextFinder from text view
On 14 Apr 2015, at 13:11, Shane Stanley sstan...@myriad-com.com.au wrote: On 14 Apr 2015, at 8:39 pm, Mark Wright blue.bucon...@virgin.net wrote: It would seem that in both your cases NSTextView should be fully aware of all this by itself. Perhaps the problem is in switching the NSTextStorage out without notifying the text view of the change? Are you swapping the textStorage instance completely? Perhaps changing it’s content and wrapping with editing calls would work? : [textStorage beginEditing]; [textStorage setAttributedString:theNewAttributedString]; [textStorage endEditing]; Maybe there’s another way to inform the parent textView that it’s content has been changed. FWIW, the above make no difference here. Shane, in your case I agree, -noteClientStringWillChange sounds like exactly the method that’s needed. I can’t see how to get to the textView’s textFinder either. You can get to the *findBar* with [[self.textView enclosingScrollView] findBarView] but that’s just an NSView and likely to not be helpful. If you’re not creating your own textFinder (and it seems from Martin’s experience that even if you do it doesn’t work) then the only thing I can think of is to somehow notify the textView that its content has changed and hope and presume that it has an internal mechanism for also notifying its textFinder. I implemented my own text finder and used -noteClientStringWillChange, and still no luck. What *seems* to be working is to disable incremental searching first, changing the text, then enabling it again. I use this elsewhere to get around another bug with text finder, at someone from Apple's suggestion. Depending on the state of the text finder at the time, it behaves a little differently for the first subsequent search, but that's a relatively small price to pay. But if it fails for the first subsequent search, then the crashes will still happen if the old search results are out of range of the new string. Right? It seems a lot of overhead for each time I modify the text, so maybe there's some way I can test if a search is active first. -- Shane Stanley sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ ___ 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: Getting at NSTextFinder from text view
On 14 Apr 2015, at 8:39 pm, Mark Wright blue.bucon...@virgin.net wrote: It would seem that in both your cases NSTextView should be fully aware of all this by itself. Perhaps the problem is in switching the NSTextStorage out without notifying the text view of the change? Are you swapping the textStorage instance completely? Perhaps changing it’s content and wrapping with editing calls would work? : [textStorage beginEditing]; [textStorage setAttributedString:theNewAttributedString]; [textStorage endEditing]; Maybe there’s another way to inform the parent textView that it’s content has been changed. FWIW, the above make no difference here. Shane, in your case I agree, -noteClientStringWillChange sounds like exactly the method that’s needed. I can’t see how to get to the textView’s textFinder either. You can get to the *findBar* with [[self.textView enclosingScrollView] findBarView] but that’s just an NSView and likely to not be helpful. If you’re not creating your own textFinder (and it seems from Martin’s experience that even if you do it doesn’t work) then the only thing I can think of is to somehow notify the textView that its content has changed and hope and presume that it has an internal mechanism for also notifying its textFinder. I implemented my own text finder and used -noteClientStringWillChange, and still no luck. What *seems* to be working is to disable incremental searching first, changing the text, then enabling it again. I use this elsewhere to get around another bug with text finder, at someone from Apple's suggestion. Depending on the state of the text finder at the time, it behaves a little differently for the first subsequent search, but that's a relatively small price to pay. It seems a lot of overhead for each time I modify the text, so maybe there's some way I can test if a search is active first. -- Shane Stanley sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ ___ 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: Getting at NSTextFinder from text view
On 14 Apr 2015, at 9:19 pm, Martin Hewitson martin.hewit...@aei.mpg.de wrote: But if it fails for the first subsequent search, then the crashes will still happen if the old search results are out of range of the new string. Right? No, there's no crash -- and it doesn't fail. In fact, the odd behavior I was alluding to actually seems to be a normal inconsistency in the find bar's behavior. -- Shane Stanley sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ ___ 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: Getting at NSTextFinder from text view
On 14 Apr 2015, at 14:22, Shane Stanley sstan...@myriad-com.com.au wrote: On 14 Apr 2015, at 10:05 pm, Martin Hewitson martin.hewit...@aei.mpg.de wrote: Hmm, are you sure about this? I was just able to produce one. In my first text storage I have a long string and search for a common word like “the”. Then I switch to the second text storage which has a much shorter string and: This is what I'm doing in my text view subclass: [self setIncrementalSearchingEnabled:NO]; [self.textFinder noteClientStringWillChange]; // modify textStorage here [self setIncrementalSearchingEnabled:YES]; Seems to be working in my (admittedly limited) testing. Yeah, that’s what I’m doing, and I managed to create that crash. When you modify the textStorage, do you swap it out? I’m doing [self.layoutManager replaceTextStorage:textStorage]; -- Shane Stanley sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ ___ 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/martin.hewitson%40aei.mpg.de This email sent to martin.hewit...@aei.mpg.de ___ 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: Getting at NSTextFinder from text view
On 14 Apr 2015, at 11:18 pm, Martin Hewitson martin.hewit...@aei.mpg.de wrote: Yeah, that’s what I’m doing, and I managed to create that crash. When you modify the textStorage, do you swap it out? I’m doing [self.layoutManager replaceTextStorage:textStorage]; No -- I'm doing: [[self textStorage] setAttributedString:string]; -- Shane Stanley sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ ___ 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: Getting at NSTextFinder from text view
On 13 Apr 2015, at 11:17 pm, Mark Wright blue.bucon...@virgin.net mailto:blue.bucon...@virgin.net wrote: To hide the find bar I use the following: [self.textFinder performAction:NSTextFinderActionHideFindInterface] I guess if I go that option, I can just message the text view. At this stage the main thing is to stop the crashes. Thanks! -- Shane Stanley sstan...@myriad-com.com.au mailto:sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ http://www.macosxautomation.com/applescript/apps/ ___ 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: Getting at NSTextFinder from text view
Hi Shane, The way I’ve been doing this is to keep hold of my own text finder in my NSTextView subclass: self.textFinder = [[NSTextFinder alloc] init]; then to set it up like this: [self.textFinder setClient:self]; [self.textFinder setFindBarContainer:[self enclosingScrollView]]; [self setUsesFindBar:YES]; [self setIncrementalSearchingEnabled:YES]; then when I want to switch out the text (because I’m changing the underlying text storage) I do [self.textFinder cancelFindIndicator]; [self.textFinder noteClientStringWillChange]; Unfortunately I still get reports of crashes similar to what you report. I’ve even made a test project that shows that doing this doesn’t fix the problem. On switching the text storage, the find bar stays visible (even though I’m calling -cancelFindIndicator, probably because this isn’t supposed to hide the find bar, and I don’t know how to do that), and hitting enter again to get the next search result shows a false result. If that result would be out of bounds of the new text string, then a crash will happen, of course. I’m happy to share my test project, if you are interested. And I’d be really happy to hear about a way to deal with this. I’ve been in touch with Apple and even provided my test project, but that was a long time ago, and still the issue remains. So either there is a bug, or I’m doing something wrong in swapping out the text storage for the text view. Cheers, Martin On 13 Apr 2015, at 04:00, Shane Stanley sstan...@myriad-com.com.au wrote: My document window includes several text views, all with find bars and incremental searching enabled, and searching works as expected. However, if I change the contents of a view via its text storage, and the user is in the middle of a search (that is, the gray overlay is showing with finds highlighted), I get either a crash (out-of-range error) or nonsense highlighted (the same ranges highlighted even though the content differs). It looks to me like I need to call either -cancelFindIndicator or -noteClientStringWillChange on the text finder before I change the text. But I can't see how I can actually get hold of the frameworks-provided text finder to message it. I fear I'm missing something simple. Any clues? -- Shane Stanley sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ ___ 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/martin.hewitson%40aei.mpg.de This email sent to martin.hewit...@aei.mpg.de ___ 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: Getting at NSTextFinder from text view
On 13 Apr 2015, at 5:31 pm, Martin Hewitson martin.hewit...@aei.mpg.de wrote: The way I’ve been doing this is to keep hold of my own text finder in my NSTextView subclass: snip Unfortunately I still get reports of crashes similar to what you report. You almost had me convinced, until I read that last line ;-) I’m happy to share my test project, if you are interested. I am, thanks. -- Shane Stanley sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ ___ 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
Getting at NSTextFinder from text view
My document window includes several text views, all with find bars and incremental searching enabled, and searching works as expected. However, if I change the contents of a view via its text storage, and the user is in the middle of a search (that is, the gray overlay is showing with finds highlighted), I get either a crash (out-of-range error) or nonsense highlighted (the same ranges highlighted even though the content differs). It looks to me like I need to call either -cancelFindIndicator or -noteClientStringWillChange on the text finder before I change the text. But I can't see how I can actually get hold of the frameworks-provided text finder to message it. I fear I'm missing something simple. Any clues? -- Shane Stanley sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ ___ 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
