Re: Using control:didFailToFormatString:errorDescription:
Re: Using control:didFailToFormatString:errorDescription:
- Subject: Re: Using control:didFailToFormatString:errorDescription:
- From: Matt Neuburg <email@hidden>
- Date: Tue, 09 Sep 2008 08:48:56 -0700
- Thread-topic: Using control:didFailToFormatString:errorDescription:
On Tue, 9 Sep 2008 12:10:10 +1000, Rohan Lloyd <email@hidden> said:
>
>On 9 Sep 2008, at 12:48 AM, Matt Neuburg wrote:
>
>> On Mon, 8 Sep 2008 11:23:30 +1000, Rohan Lloyd <cocoa-
>> email@hidden> said:
>>> I don't like the vague "Format Error" and want to display my own
>>> message, so I've written my own
>>> control:didFailToFormatString:errorDescription: method (In my
>>> NSWindowController subclass), and set the text field delegate to
>>> point
>>> at it.
>>>
>>> - (BOOL)control: (NSControl*)control didFailToFormatString:
>>> (NSString*)str errorDescription: (NSString*)errDescription
>>> {
>>> NSError *error = [NSError errorWithDomain: NSCocoaErrorDomain
>>> code: NSFormattingError userInfo: nil]; // Add custom description
>>> later
>>> [control presentError: error modalForWindow: [self window]
>>> delegate: nil
>>> didPresentSelector: nil
>>> contextInfo: nil];
>>>
>>> return YES;
>>> }
>>
>> First thing's first. Documentation says return value should be:
>>
>>> Return Value
>>> YES if the value in the string parameter should be accepted as is;
>>> otherwise,
>>> NO if the value in the parameter should be rejected.
>>
>> If you don't like the string, you should not be returning YES. m.
>
>You're right I should have read that part of the documentation.
>However, I had tried returning NO, and it didn't really help.
>
>If I return NO, not only do I get my error displayed, but the standard
>error dialog is also shown. Which suggests that the return value is
>overloaded with a "I have handled this error" meaning. This is backed
>up by the following page that I read:
>
> ://initgraf.blogspot.com/2007/11/customizing-errors-generated-by.html
>
>Where it says, "You need to return YES, or else you'll get both your
>custom error and the standard error."
Okay, well, that's why I preceded my reply with the phrase "first thing's
first". What I meant by that was: If you insist on using
control:didFailToFormatString: it's probably a good idea to use it in
accordance with the documentation. But now we're ready for the real issue,
which is, is it right to be using control:didFailToFormatString: at all? It
seems to me that this does not supplement or modify, but rather conflicts
with, the normal pattern of validation. Now that you've revealed where
you're getting the idea to use control:didFailToFormatString:, I wonder
whether you're following a dangerous white rabbit down an even more
dangerous rabbit hole.
IIRC, your original complaint was that you have text fields in a sheet bound
to an NSObjectController and when the user tries to tab out of one of these
fields you want an invalid value to result in (1) presentation of your
customized message and (2) the user winding up back in the bad field. The
way I would do this is to implement validateValue:forKeyPath: in the
NSObjectController, where the NSObjectController, not the text field, is
holding on to the formatter. (The text field's binding should include
"validates immediately".)
For an example, take a look at my NotLight application. Choose Window > Date
Assistant and enter -3 into the Relative Times text field. Now try to tab
out or to use the corresponding Use This button. You will see a custom error
message and if you click Cancel you will fall back into the invalid field.
Isn't that just what you say you're trying to do?
And notice that because this approach *uses* the validation mechanism rather
than fighting against it, there is no need to call presentError: as in that
blog post. The NSError that you create in validateValue: *is* the error that
will be presented - for you, by the validation mechanism.
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
One of the 2007 MacTech Top 25: <http://tinyurl.com/2rh4pf>
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
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