NSFormatter bugs
NSFormatter bugs
- Subject: NSFormatter bugs
- From: Bill Cheeseman <email@hidden>
- Date: Sat, 02 Mar 2002 06:34:42 -0500
There appear to be two bugs in NSFormatter's new (with X 10.0), longer form
of the isPartialStringValid:... command, used to implement on-the-fly
filtering and formatting in text fields. I'm looking for confirmation that
these are bugs, and also that my workarounds are sensible. I raised these
issues here a year ago, and now I want to try again to see whether I can
learn anything new.
1. The origSelRange parameter value is incorrect after the user presses the
Delete key. origSelRange.location reports the new location AFTER the Delete
key was pressed, instead of the old location BEFORE the Delete key was
pressed as it should. Also, origSelRange:length reports 1, instead of 0 as
it should when nothing was selected before pressing Delete.
This bug makes it impossible to write a proper NSFormatter subclass that can
distinguish between pressing the Delete key and pressing the Forward Delete
key. This is because the Forward Delete key reports the same location and
length (the location is correct in the case of the Forward Delete key, but
the length is also incorrectly reported as 1 even though nothing was
selected before pressing Forward Delete).
The workaround is to use NSApp to parse the keyDown event. However, this is
improper formatter design because it requires importing the AppKit, whereas
formatters are supposed to live in Foundation so that they can be used in
non-AppKit software. Here's the workaround:
bool deleting =
(([[[NSApp keyWindow] currentEvent] type] == NSKeyDown) &&
([[[[NSApp keyWindow] currentEvent] characters]
characterAtIndex:0] == NSDeleteCharacter));
2. The field editor's selection is not updated if, after the user Deletes or
Forward Deletes the second-to-last character in the text field, the
formatter removes the last character in the text field (for example, a
separator character that should be removed once there are no "real"
characters in the text field). The text field's insertion point is left in
an anomalous condition, ignoring the text field's justification setting and
with only the top half of the blinking insertion point visible.
The workaround is to explicitly reset the field editor's selection at the
end of the formatter's isPartialStringValid:... override:
if ([*partialStringPtr length] == 0) {
[[[NSApp keyWindow] fieldEditor:NO forObject:nil]
setSelectedRange:*proposedSelRangePtr];
}
Again, this is incorrect formatter design because it requires NSApp from the
AppKit.
Am I overlooking something? Are there workarounds that don't require the
AppKit? I wonder if I could fix both of these with a category on NSFormatter
(which would still require NSApp)?
Yes, I've reported both bugs to RadarWeb.
I would love to hear from the Apple engineer who wrote the new version of
isPartialStringValid:..., but I don't know who that might be. I have sample
code that can be used to test this.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.