On 14 Apr 2015, at 11:18 pm, Martin Hewitson 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] setAttri
> On 14 Apr 2015, at 14:22, Shane Stanley wrote:
>
> On 14 Apr 2015, at 10:05 pm, Martin Hewitson
> 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 se
On 14 Apr 2015, at 10:05 pm, Martin Hewitson 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
> On 14 Apr 2015, at 13:30, Shane Stanley wrote:
>
> On 14 Apr 2015, at 9:19 pm, Martin Hewitson
> 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 cra
On 14 Apr 2015, at 9:19 pm, Martin Hewitson 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
alludi
> On 14 Apr 2015, at 13:11, Shane Stanley wrote:
>
> On 14 Apr 2015, at 8:39 pm, Mark Wright 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
On 14 Apr 2015, at 8:39 pm, Mark Wright 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 ins
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, a
On 13 Apr 2015, at 11:17 pm, Mark Wright 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
On 13 Apr 2015, at 5:31 pm, Martin Hewitson wrote:
>
> The way I’ve been doing this is to keep hold of my own text finder in my
> NSTextView subclass:
>
>
>
> Unfortunately I still get reports of crashes similar to what you report.
You almost had me convinced, until I read that last line ;
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]];
[sel
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
hig
12 matches
Mail list logo
