On Nov 11, 2008, at 17:21, Ashley Clark wrote:
If you want to make sure that the validation error is bound to the
window regardless of how commitEditing is implemented you need to
call commitEditingWithDelegate:didCommitSelector:contextInfo: and
then in the method you pass in as the didCommitSelector you can
check to see if there were any errors and then use
presentError:modalForWindow:delegate:didRecoverSelector:contextInfo:
to attach them to your window.
Whether commitEditing should be showing a separate window or a sheet
is not documented anywhere that I see, whether that's a bug or a
feature I'm not sure.
commitEditing always uses a separate alert window because it is
synchronous (doesn't return till the alert is dismissed). Only
asynchronous things use sheets.
Remember also that bindings-triggered validation (via the
validate<key> method) uses a sheet, but only after the next pass
through the run loop. And closing the window doesn't trigger anything
by default. Or quitting the application. And there are interactions
between undo and text fields that are actively being typed in.
The semantics of committing edits in a long-lived window like a
document window seem rather tricky to me. In the end, I gave up trying
to do it, and used dialogs (sheets) with good ol' OK and Cancel
buttons instead.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
