On Dec 1, 2014, at 1:08 PM, Andreas Höschler <ahoe...@smartsoft.de> wrote:
> Hi Kyle,
>
>>> Adding
>>>
>>> #ifdef __APPLE__
>>> - (void)setWindow:(NSWindow *)window
>>> {
>>> }
>>> #endif
>>>
>>> to my GSScrollView : NSScrollView subclass fixed (or at least worked
>>> around) the issue (no exception anymore and no apparent malfunction of the
>>> app).
>>
>> WOAAAAAHHHH. This is NOT the way to solve this problem!
>
> Of course not!! But it at least makes the application available for the time
> being (needed to be urgently fixed or at least worked around).
>
>> NSView and NSScrollView (may) do important work in -setWindow:! You just
>> haven't noticed what you’ve broken yet.
>
> I have posted the methods and ivars I have added to my subclasses. I can't
> see any obvious conflict with Apples API modifications!? And the app crashes
> in setWindow!? I see it that way. Apples implementation of
> NSScrollView::setWindow looks probably similar to this:
>
> - (void)setWindow:(NSWindow *)window
> {
> // remove observer for _window::contentLayoutRect
> [_window release];
> _window = [window retain];
> ...
> // add observer for _window::contentLayoutRect
> }
>
> Do you agree?
No, because that's a really bad design pattern. It can bite you if you aren't
careful - if, say, you don't call setters in dealloc because of KVO-triggered
side effects, or anything else where the window's dealloc is called when you
don't expect it. (Also I expect it's using ARC)
Since you can add observers on keypaths, I would do
[self addObserver:self forKeypath:@"window.contentLayoutRect"...
instead of
[window addObserver:self forKeypath:@"contentLayoutRect"...
And also, because it fits the behavior I've seen in other Apple bugs, the
problem might be that there's not a "setWindow:nil" in there when it's all done
- I have seen things that indicate they don't set delegates to nil, and since
delegate is a weak ref, that means it can be dead and still referenced. Fine if
everything is ARC, but not so good when there's a mix.
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
