On Nov 20, 2009, at 09:11, Scott Ribe wrote: > The crude approach of "[[self window] makeFirstResponder: nil];" seems to > work well enough. (I'd previously tried a couple of other things along those > lines and failed.)
Maybe I missed something earlier in this thread, but I don't see why using the NSEditor protocol isn't a better solution. This solution may take a bit of preparation, because it's easiest if everything that needs to be committed (when the button is pressed) is bound to some kind of NSController (which implements both NSEditor and NSEditorRegistration). The table view is bound to a NSArrayController for its content, and if there are any freestanding text fields, they should be bound via a NSObjectController rather than directly to the window controller or data model. Then, the action routine for the button-press simply needs to invoke 'commitEditing:' on each of the relevant NSController objects, and everything should get committed. This is a superior solution to the 'makeFirstResponder:' approach, I believe, because it tells you if committing fails due to a validation error -- in which case I assume you wouldn't want to proceed with whatever the button normally triggers. The only drawback is that you need to know which NSController objects to send the 'commitEditing:' message to, which introduces a certain element of fragility into the code. Note that it's not absolutely necessary to introduce the NSObjectController objects, since the window controller could send 'commitEditing:' messages directly to text fields and other views that implement the NSEditor protocol. However, I believe, NSController has some kind of unified error reporting model (which defers reporting of the error till the next iteration of the run loop), so it seems useful to buy into that mechanism by routing everything through a NSController. Finally, there *is* a more general solution, which is to subclass NSWindowController and implement both the NSEditor and NSEditorRegistration protocols, much like NSController does. That implementation would have to keep track of registered editors (which implies that the editors must be bound to the window controller's properties, since that's apparently how an editor figures out which object to register with), but that doesn't seem too hard. [The simplest implementation would also require that everything be bound via a NSController, as above, so that the window controller could leverage the NSController's NSEditor/NSEditorRegistration implementation.] It would then just be necessary for the button action routine to invoke 'commitEditing:' on the window controller itself, which eliminates the fragility I mentioned above. Further, by registering itself as an "editor" with the NSDocument object (in a document-based app), the window controller would then get the 'commitEditing:' message automatically whenever the document was saved etc (as spelled out in the release notes, as mentioned earlier in the thread), eliminating the need to handle that situation manually. At least, that's my understanding about how these protocols are supposed to work, deduced from experimentation and the rather murky documentation. _______________________________________________ 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 arch...@mail-archive.com
