I don't feel that I am relying on the delegate methods to capture any state change; all I'm doing in control:isValidObject: is validating the object and returning NO when it is invalid. According to the documentation, that's exactly what you're intended to do in that method.
I've confirmed my suspicion that edits are getting committed to the NSTextField (or rather, the NSTextFieldCell) even when control:isValidObject: returns NO. I subclassed NSTextFieldCell and overrode setObjectValue:, and it is getting called and passed the edited value even before control:isValidObject: gets called on my delegate. While I can't find anywhere in the docs that explicitly say it, I assumed that the field editor would not commit the edit (that is, call setObjectValue:) until after calling control:isValidObject:, and even then only if that method returns YES. I'm not sure whether this should be considered a bug since as I said I can't find anything to the contrary in the documentation, but if others think it's worthwhile I'll file a radar for it. It occurs to me however that the documentation for [NSTextField textShouldEndEditing:] says that it first calls isEntryAcceptable: on the cell and then calls control:textShouldEndEditing: on the delegate if the previous method returns YES. My guess is that in between those two it calls setObjectValue: on the cell without waiting to see what is returned from control:textShouldEndEditing:. Perhaps I can subclass NSTextFieldCell and override isEntryAcceptable: and do my validation there instead, in the hopes that returning NO from that method will prevent the field editor from calling setObjectValue: on the cell. On Jul 11, 2013, at 3:14 PM, Quincey Morris <quinceymor...@rivergatesoftware.com<mailto:quinceymor...@rivergatesoftware.com>> wrote: On Jul 11, 2013, at 11:23 , Matthew LeRoy <mle...@minitab.com<mailto:mle...@minitab.com>> wrote: I had previously considered the same approach you suggested regarding adding to the checkbox's action method. The problem is that our desired behavior is to allow the checkbox to be unchecked at any time, and any uncommitted edits simply be discarded whether they are valid or not. Relying on the text field delegate methods to capture the change of state in every sequence of events seems fragile. You should probably approach this by having your checkbox action method adjust the value of the text field directly, just after disabling it. Either set the text field to "not available" when disabling, or validate the input and discard invalid values. You might additionally choose to re-validate the text field value later, when it's actually used (or committed to your data model). That way, if there's a scenario you've overlooked that would leave invalid input in the field, it can't propagate to the data model. Incidentally, I'd suggest that the reason you're running into an issue is that you "really" have a composite control, but you're "simulating" it via a pair of separate controls. It's not very surprising in that case that you might have to code the relationship between the controls explicitly. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
