[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSWindow and delegate methods
|
From: |
Ivan Vučica |
|
Subject: |
Re: NSWindow and delegate methods |
|
Date: |
Fri, 20 Sep 2013 01:40:08 +0200 |
(Note to self: it's good to respond to the mailing list instead of just the message author.)
---------- Forwarded message ----------
From: Ivan Vučica
Date: Friday, September 20, 2013
Subject: NSWindow and delegate methods
To: Fred Kiefer <address@hidden>
On Thursday, September 19, 2013, Fred Kiefer wrote:
It looks like I added the check for these methods being send to self
about ten years ago. But I don't have any recollection of this. So the
best I can do is look up the Apple documentation for zoom:. There it says:
"Invokes the windowWillUseStandardFrame:defaultFrame: method, if the
delegate or the window class implements it, to obtain a “best fit” frame
for the window. If neither the delegate nor the window class implements
the method, uses a default frame that nearly fills the current screen,
which is defined to be the screen containing the largest part of the
window’s current frame."
I am now a bit unsure what is meant by "the window class". When
implementing the code I thought the method should be called on the
window itself, but it might as well be the class of the window. Later on
for windowShouldZoom:toFrame: the documentation is more clear.
This means that removing this call is not a valid option.
Indeed, you're (as always!) right - Apple's text is very clear on this, and subclasses can implement this method. I did not see this.
Moving away
from defined behaviour, just because the code gives warnings on some
overambitious compiler isn't enough reason.
The trouble is I was not getting warnings -- I was getting errors. This is because many of these 'delegate' methods don't return an object -- so they need a valid definition containing the correct return type.
Current solution (adding the definition to every NSObject, just like before with an informal protocol) seems less than ideal, because it brings us right where we started. We might as well define the formal protocol to be empty.
I would also think that Greg's fix is not correct, as it removed the
method from the delegate protocol. It looks like in the case of an
optional protocol we need to duplicate the definitions, once in the
protocol and again in an NSObject extension.
Greg's fix (adding a category that happens to implement the formal protocol) did add the methods back into NSObject, at least for me, so I no longer get the errors that I did when he first moved the methods to @protocol.
Thing is, should these methods be declared in NSObject? Should we keep supporting the informal protocol once we support the formal one?
--
--