On Mar 5, 2011, at 11:03, Jonathan Taylor wrote: > I think I see what you're saying, but my motivation was based on a similar > philosophy I think: if the user has accidentally typed something > non-numerical into the "lower x" field, I was thinking they would be rather > surprised if clicking on "send" caused the GUI to suddenly start complaining > about "lower x" not being valid and refusing to send raw stage commands until > that unrelated issue was rectified.
Your point is valid too. :) I think you need to make a distinction between validation time (which happens when the Send button is pressed) and commit time (which has to have happened before validation time, immediately before if not sometime earlier). Therefore, pressing the button should cause 'commitEditing' to be invoked for at least the text fields the action depends on, so that validation of those fields uses the correct values -- as will the action itself. That's what you've got now. What you're also doing now (or proposing to do now) is using the UI text fields that are *not* related to the Send button as ad-hoc temporary storage for unvalidated values. That's why you're trying to prevent them from being committed "too early". As you've seen, this is terribly fragile, because your app is not necessarily in full control of the field editor state. You could code around this fragility and hope for the best (which would probably be pretty good, if you use an object controller per text field group), or you could let go of the requirement that's causing the trouble. It doesn't seem necessary to require that text fields should not get committed at other times. That is, you don't want to validate text fields at commit time, but at action time. (Sometimes the same thing, but not always.) Once you let go of that, things get much easier as far as the field editor state is concerned. There may actually be extra work with this approach, though. If your data model can't tolerate invalid values being committed (such as the non-numerical "lower x" field), you may have to bind the UI text fields to intermediate properties in your window controller (real temporary storage for unvalidated values), and have your validation code transfer the validated values to the data model when needed. But that doesn't sound necessary in your case -- you've basically said that nothing cares what "lower x" is until the time comes to use it. It's possible, perhaps even likely, that I'm over-thinking this, but I've found in the past that putting text fields in a main window like this, especially when the values are intended to be "picked up" by a button press, is an extremely subtle UI problem, one that's very hard to get right. It's actually better *not* to use naked text fields**, and to use something like a sheet to enter the values, but it sounds like that's too inconvenient in your application. FWIW ** It's an interesting exercise to go through your Applications folder and see if you can find *any* app that has naked text fields in a main window. You'll find some search fields in toolbars, and you'll find some text fields in floating/inspector windows, but you'll be lucky to find any apps that solve the UI problem you're dealing with here. _______________________________________________ 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
