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
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
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,
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
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
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
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
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
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
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]];
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
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
12 matches
Mail list logo
