On 2009 Jul 08, at 16:20, Quincey Morris wrote:
Excuse me while I put on my properties-are-behavior crusader's hat. :)
OK, I get it. Since we don't always use @synthesize, @dynamic, or
Xcode's "Scripts" menu (noting the if() test in this implementation) ...
- (void)setName:(NSString *)value {
if (name != value) {
[name release];
name = [value copy];
}
}
the property can be a behavior.
When undoing an action, all setters that were called during the
action need to be called again, in the correct order, even if the
getter value doesn't change as a result.
Maybe this is one of the reasons why it is quite common nowadays that
when a user clicks "Undo" 10 times, something is seen to happen on
only 5 or 6 of the clicks.
On 2009 Jul 08, at 16:49, Kiel Gillard wrote:
To prevent this behaviour, you could override setName: to only
change the value when the pointers are not the same.
In other words, return before the -willChangeValueForKey tells KVO
about it. Actually, I've done that on occasion. Yes, the filtering
can be done on the front end instead of the back end. That's a good
thing to keep in mind.
Thanks to all who replied. I don't feel so bad about having to do the
filtering now.
_______________________________________________
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
