KVO: when to stop observing?
Hi, In my program, I rely heavily on key-value observing (KVO), which I find really useful. However, I haven't found a good way to know when I should stop observing, i.e. call removeObserver:forKeyPath:. Until now, my solution has been to start observing in the designated initialiser, and to stop observing in the dealloc method. This solution kind of works, but has several drawbacks: 1. It doesn't work with GC, first because GC doesn't call dealloc and second because the simple fact that my object is registered as an observer probably prevents it from being collected in the first place (I haven't checked, but that's what I gather from messages found in this list's archive). Even if it didn't, stopping the observation in finalize wouldn't be ideal, as object would keep getting notifications for some time after becoming unreachable. 2. I have to be careful when I use this technique on CoreAnimation layers, since CA uses the initWithLayer: method to create presentation layers during animations. If initWithLayer: doesn't invoke the designated initialiser, then the presentation layer doesn't observe anything, and the program crashes when its dealloc method tries to call removeObserver:forKeyPath:. The solution I have found for this is to keep track of whether a layer is a presentation layer or not, and only call removeObserver:forKeyPath: for non- presentation layers. That's ugly. Overall, I have something that works but isn't elegant at all. I'm therefore looking for better solutions, and would be interested to know what people have come up with. It seems to me that the only clean solution would be to detect when an object is dead and then call a method to make it stop all its observations, but this is equivalent to solving the memory management problem by hand, which is painful. Thanks, Michel. ___ 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
Re: NSTextField as a CALayer
Le 1 déc. 08 à 07:45, Scott Anguish a écrit : No, you can't do this. Core Animation is designed for easy animation, but not so you can freely mix views and layers like this. you could probably do what you want by doing your current CALayer drawing into an NSView, and then add the textfield as a subview of that view.. then turn on layer backing for the parent NSView. Indeed, that's what I personally do in my application, and it works well with some minor gotchas, one of which was explained to me by the always-helpful David Duncan in the following thread (which the OP might find worth reading): http://www.cocoabuilder.com/archive/message/cocoa/2008/11/14/222642 Michel.___ 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 [EMAIL PROTECTED]
Adding an NSButton to a layer-hosted view
Hi, I have a layer-hosted view containing several layers making up the UI of my application. In a few cases, I would actually like to use standard controls *inside* of this layer-hosted view. For example, I'd like to have a standard NSButton in one location, and use an NSTextField to edit some text in another location. What I've done until now is to create the NSButton/NSTextField in the standard way, then add them as sub-views of my main view. Once this is done, I obtain the layer property of those objects and manipulate this layer like the other ones, to position them, set their z- position, hide or show them, and so on. This seems to work relatively well, except that the NSButton instance does not react to mouse events. For example, it does not perform the action or toggle its state when I click on it. Instead, my layer- hosted view gets the event (i.e. its mouseDown: method gets invoked). I found a partial work-around, which consists in calling performClick: on the button whenever its layer is the one under the mouse when the click happens, but this is not satisfactory (e.g. the button does not highlight when the mouse hovers over it, even though it should, given how it's configured). So I have two questions: 1. Is it actually valid to add an NSButton or NSTextField as a sub- view of a layer-hosted view? 2a. If it is, then how do I make sure the NSButton I add reacts to mouse events as it should? 2b. If it isn't, then is there a better way to do what I'm trying to do, i.e. have a view containing many many layers managed directly by my application, with a few standard controls mixed in? Thanks, Michel. ___ 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 [EMAIL PROTECTED]
Re: Adding an NSButton to a layer-hosted view
Le 14 nov. 08 à 18:04, David Duncan a écrit : AppKit doesn't do hit testing via the layer tree, so by moving the button's layer, you've desynchronized the graphical location of the button with the hit test location of the button. If you want to use layer-backed AppKit views, you always need to move them via AppKit for the graphical and logical locations to match. That was the problem indeed, thanks a lot David! Moving the button using setFrameOrigin: makes it behave correctly. I'll also conclude from your answer that putting these NSControl instances in my layer-hosted view is legal. Please correct me if I'm wrong. Michel.___ 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 [EMAIL PROTECTED]