1. From Apple’s NSTextFinder class guide
<https://developer.apple.com/reference/appkit/nstextfinder>:
> For example, if a client had the strings “The quick”, “brown fox” , “jumped
> over the lazy”, and “dog”, and a NSTextFinder instance requests the string
> at index 18, then the client should return "brown fox”. If all the strings
> were concatenated together would be the ‘x’ in "fox". Additionally, the
> client should return, by-reference through the outRange parameter, the
> effective range of the string that is returned. In this example, the range of
> “brown fox” is {9, 10}, because, in the imagined concatenation, the substring
> starts at index 9 and is 10 characters long.
Is there a off-by-one bug with the end of the second string? Or am I really
misunderstanding Apple’s counting strategy? The second string seems to be only
9 characters long. And shouldn't index 18 point to the first character of the
third string instead? (Well, the 18 is right assuming the length of 10 is
actually right. But it isn’t, so it’s not.)
2. Since the first half of my data is in a table view, I guess I’ll supply a
list of ranges for the cells’ text and flag that matches shouldn’t straddle
boundaries. But should my text for the second half (i.e. the text view) be
included in that list (going Make-Range(first-half-length,
second-half-length))? Or as a separate string for the text view’s find bar
(going Make-Range(0, second-half-length))?
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
