Re: Bug in NSFormatter (again)?
Re: Bug in NSFormatter (again)?
- Subject: Re: Bug in NSFormatter (again)?
- From: Bill Cheeseman <email@hidden>
- Date: Sun, 05 Aug 2001 17:30:55 -0400
on 8/5/01 4:23 PM, Chris Kane at email@hidden wrote:
>
These wouldn't be bugs in NSFormatter, btw. They would be bugs in
>
whoever is using the formatter. For example, an NSFormatter doesn't
>
call it's own -isPartialStringValid:.... methods (unless your subclass
>
does), it's the NSCells or whatever else is using the formatter that may
>
be using the formatter incorrectly, or passing the wrong arguments to
>
the formatter methods, or mis-setting the caret/selection after
>
formatting, etc.
I understand what you're saying, but I still think it is likely to be a bug
within NSFormatter itself. I have written a custom formatter that implements
the new, longer isPartialStringValid:... method. I assume there is private
code within NSFormatter that makes use of the parameter values that are
returned by reference when this method is overridden by a subclass, in order
to pass them to clients to actually set the new, edited value of the text
field to which the custom formatter is attached, and to set up its insertion
point. Right? I suspect it's that private code that has a problem, because
all I do is attach the formatter to a text field. Cocoa is supposed to take
care of the rest.
In any event, the built-in Cocoa routines that use the *proposedSelRangePtr
value, wherever those routines are located, must be doing something wrong in
this boundary situation (i.e., a zero-length string), at least in some
circumstances. Using NSLog(), I check the value of *partialStringPtr and
proposedSelRangePtr->location as my subclass's override of
isPartialStringValid:... is about to exit, and again after it has exited,
and they are correct (i.e., an empty string object, a selection location of
0, and a selection length of 0.
When I look at my own code for the override method, the only thing that
looks odd is the fact that *isPartialStringPtr has a retain count of -1 as
the method exits in the case that errors, but it has a retain count of 1 in
all other cases. But I can't find any way to increment it. If I do a retain
on it just before the method exits, it remains -1 when tested after the
method has exited.
On the execution path that errors, I start by setting *partialStringPtr to
@"". If I check the retain count of *partialStringPtr immediately, it is -1,
which seems odd. And it is -1 at exit, even if I retain it repeatedly.
Perhaps I still don't understand retain well enough, especially in the
context of a pointer to an object passed by reference in a method parameter.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
The AppleScript Sourcebook - www.AppleScriptSourcebook.com
Vermont Recipes - www.stepwise.com/Articles/VermontRecipes