Pregunta

I have an NSTextView which I programmatically create within the content view of my window. Under certain circumstances I need to programmatically terminate the edit and destroy the NSTextView. When I do this (by setting first responder to nil, removeFromSuperview and releasing my pointer) the dealloc on the NSTextView is not called - until I move my mouse outside of the window content view. It's as though the window is caching a reference to the NSTextView and only releasing it when it decides that I'm no longer interacting with the window. This wouldn't be a problem except that this then messes up the undo grouping for the associated textContainer.

Bit of an obscure one - but if anyone has any knowledge of this I'd love to hear from you!

Thanks

¿Fue útil?

Solución

Still don't know why NSTextView deallocation is deferred - but it turns out that was a red herring anyway. The reason my undo stack was getting trashed was because I was destroying my NSTextView inside my textDidChange callback (albeit with a retain/autorelease to defer the actual dealloc.)

If I defer my destroyTextView: code by calling it by performSelector:withObject:afterDelay from my textDidChange then all is well (with the undo stack.)

Makes sense now I've found the reason...doesn't it always?

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top