On Dec 20, 2008, at 22:00, Graham Cox wrote:
If the UI is part of an inspector-type interface, i.e. modeless,
then just make the change but do it undoably. Performing the Undo
naturally updates any visible UI that matters (KVO/Bindings makes
this trivial).
The main case where a Save/Cancel approach makes much sense is in a
modal situation, in which case the OK/Cancel buttons already imply
the answer - Save on OK, revert on Cancel. Or, if you prefer for a
modeless dialog, present an alert on window close, though I dislike
this myself - a modeless window might as well use Undo, unless it's
editing a very specific aspect of the data model, such as user
defaults, where it's not usually appropriate to use Undo. Bear in
mind you can create an undo manager at any time.
The UI is using a single window (per database relations) with the
master table on the left and detail on the right. I've struggle a lot
with this as the detail view in the principal table is pretty complex:
25 fields (although many are generated) and 2 table views (to many
relationships). In a typical session, the window will be closed at the
end of the day. In the present application (built with 4th Dimension)
the window contains the list and users must double-clic on a row to
edit a record. Since they often need to check the detail view for a
couple of rows before making a decision, I thought it would be great
to use a master/detail design. This has some side effects though,
hence my reason for using the alert...
I will think on the implications of using Undo as there's some limit
to this design. The first thing I must resolve is Undoing changes
hours or days after entries... Using (database row) versions is
expansive as there's more than a million rows spread over many
database tables. Not counting the legal implications when saving data
to the wrong "client". The present design doesn't always prevent this
but gives a more immediate feedback to the user, as "annoying" as it
may sounds...
Thanks for the comments, I will sleep on this :-)
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
