On Dec 21, 2008, at 09:27, Andreas Mayer wrote:
All these cases somehow involve user errors. If this really is a problem, why not introduce a separate edit mode? I.e. in browse mode all fields in the detail pane are locked as in *not* editable. To edit anything the user has to enter edit mode (by clicking a button, selecting a menu command etc.). This will unlock the fields in the detail pane and *disable* the master view. That way the user always has to end editing explicitly to change records.
I'm using a similar design, not by locking the fields but setting a "isDirty" flag in the model after the user start editing the record. This hole problem arises when I want to "disable" the master view. I thought using -selectionShouldChangeInTableView will serve this purpose but since it's called twice when returning NO, I have to work around the bug. You pointed me in the right direction though. I could probably just return NO when the record is dirty, perhaps beeping (which will happen twice), which is not as annoying as presenting the same alert two times in a row. Maybe the delegate method - selectionIndexesForProposedSelection: could be a better choice...
Thanks for the idea, Andre Masse _______________________________________________ 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
