On 02.11.2009, at 13:49, Eric Morand wrote:
The setIcon: method is successfully called when I delete the content
of the image view, sending nil as the newImage parameter. Great. But
the image view doesn't update its content. In other words, the icon
getter method is not called event though I added the willChange and
didChange calls.
You'd get endless recursion if NSImage called -icon again.
10 NSImageView -setImage: gets called when you delete
20 NSImageView -setImage: calls MyController -setIcon:
30 MyController -setIcon: calls willChange:
40 NSImageView gets the change notification and calls MyController -
icon
50 NSImageView calls -setImage: on itself to apply the icon it just
retrieved - GOTO 10
Since NSImageView knows it just called setIcon with its current value,
it expects the return value from -icon to be the same as the value it
gave to setIcon:, so while it is doing the setIcon, it ignores any
change notifications (or rather, the bindings system does that for it).
Does that clear things up? It's an inherent assumption/protection
built into bindings, and you'll need to find another way to code what
you want.
You're actually muddling the controller/view layer a bit here. If
you want different *display* of NIL, the view should really be doing
that. So overriding drawRect: might be a better solution.
Cheers,
-- Uli Kusterer
"The witnesses of TeachText are everywhere..."
_______________________________________________
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
