Is -rangeOfUserTextChange: supposed to wipe out marked text/diacritical marks?
Is -rangeOfUserTextChange: supposed to wipe out marked text/diacritical marks?
- Subject: Is -rangeOfUserTextChange: supposed to wipe out marked text/diacritical marks?
- From: Keith Blount <email@hidden>
- Date: Thu, 20 Nov 2008 12:59:14 -0800 (PST)
Hi,
I've had some bug reports from users saying that accented characters don't always work correctly in my software, but I've never been able to reproduce it - until now. It seems that calling NSTextView's -rangeOfUserTextChange: and -rangeOfUserCharacterAttributeChange: wipes out marked text in a text view, and I'm wondering if this sounds like intended behaviour before I file a bug report on this...
The problem in my case is that I call -rangeOfUserTextChange: or -rangeOfuserCharacterAttributeChange: from interface validation code (-validateUserInterfaceItem:) for certain items - for instance, to check to see whether it is currently possible to annotate some text (for which there must be some text selected that can have its attributes changed). If there is a toolbar item that calls on such validation code, suddenly accented characters stop working.
This can be easily reproduced as follows:
1) Create a simple document-based Cocoa app with just a text view in it and an outlet point to it.
2) Add a toolbar, and a toolbar item with the action -foo:.
3) Add some validation code for -foo: which calls -rangeOfUserTextChange: or -rangeOfUserCharacterAttributeChange:. Here is a simple NSDocument subclass that does this:
@implementation MyDocument
- (NSString *)windowNibName
{
return @"MyDocument";
}
- (IBAction)foo:(id)sender
{
NSBeep();
}
- (BOOL)validateUserInterfaceItem:(id < NSValidatedUserInterfaceItem >)anItem
{
if ([anItem action] == @selector(foo:))
{
(void)[textView rangeForUserCharacterAttributeChange];
return NO;
}
return YES;
}
@end
Now launch the project, make sure the toolbar item with the action -foo: is in the toolbar, and type Option-n - the tilde appears with the orange mark, but immediately the orange mark disappears, so that typing n again just leaves you with ~n instead of the expected ñ...
The only fix I have come up with is to check for marked text before calling one of the -rangeFor... methods (e.g. if ([self hasMarkedText]) return NO). But this just doesn't seem right to me.
So, before I file a bug, is there a good reason I'm seeing this behaviour? Am I missing something obvious? I now have to go through every place I've used these methods in validation code...
Thanks!
Keith
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden