Bug: CPWindowController does not call windowWillLoad and windowDidLoad when window is not loaded from cib #693

Open
klaaspieter opened this Issue May 31, 2010 · 14 comments

Comments

Projects
None yet
5 participants
Contributor

klaaspieter commented May 31, 2010

CPWindow does not call windowWillLoad and windowDidLoad when the window is set directly. For example when setting the window directly in loadWindow or initWithWindow:

Fix is here.

Contributor

Me1000 commented Aug 12, 2010

Link is broken. I assume this hasn't been fixed yet though?

Contributor

klaaspieter commented Aug 23, 2010

If I remember correctly I checked with Cocoa and it wasn't Cocoa behavior. I'll try to verify this later this week.

Contributor

klaaspieter commented Aug 23, 2010

Cocoa does not call any of the window loading methods if the window is loaded programatically.

For example if the window controller is created using initWithWindow:nil, windowWillLoad, loadWindow and windowDidLoad are never called.

I do believe this is wrong and we should move our window and view controllers to behave a bit more like those on the iPhone. Thoughts?

Contributor

klaaspieter commented Aug 23, 2010

I've filed a radar for this. The radar number is 8341312.

Contributor

aparajita commented Apr 30, 2012

I don't see how the behavior you want is like iOS. There is no windowDidLoad in iOS, and viewDidLoad says this:

This method is called regardless of whether the view hierarchy was loaded from a nib file or created programmatically in the loadView method. You usually override this method to perform additional initialization on views that were loaded from nib files.

In your example you aren't loading a window from a cib, but setting it programmatically on instantiation, not through loadWindow.

Contributor

klaaspieter commented May 2, 2012

This is a long time ago, but I do think it's still valid. If I initialize a window controller with initWithWindow:nil, I expect loadWindow to be called when the window is first requested getter.

I think no matter what, the window controller should be responsible for loading the window. Having to call initWithWindow: with a window instance breaks this principle. It makes an outside class responsible for creating the window that the window controller is going to manage.

When I say it should behave more like iOS I mean that iOS will call loadView when the view is first requested through it's getter. It is then up to the programmer to decide to override loadView to load his view programmatically or to make sure a nibName is available at that point.

Contributor

aparajita commented May 2, 2012

When I say it should behave more like iOS I mean that iOS will call loadView when the view is first requested through it's getter.

ONLY when it is loaded from a nib, NOT when it is directly set. I have done extensive testing of this behavior.

Contributor

klaaspieter commented May 3, 2012

I'm not sure I understand what you mean. As far as I know loadView is always called the first time the view is requested using it's accessor.

Contributor

aparajita commented May 3, 2012

loadView isn't the issue here, viewDidLoad is the issue.

cappbot commented May 9, 2012

Label: #new. What's next? A reviewer should examine this issue.

Contributor

aparajita commented May 21, 2012

+AppKit
+bug
#needs-reduction
#needs-review

cappbot commented May 21, 2012

Milestone: Someday. Labels: #needs-reduction, #needs-review, #new, AppKit, bug. What's next?

  • A minimal test app should be created which demonstrates the concern of this issue in isolation.
  • This issue is pending an architectural or implementation design decision and should be discussed or voted on.
Contributor

ahankinson commented Feb 14, 2013

-#new

cappbot commented Feb 14, 2013

Milestone: Someday. Labels: #needs-reduction, #needs-review, AppKit, bug. What's next?

  • This issue is pending an architectural or implementation design decision and should be discussed or voted on.
  • A minimal test app should be created which demonstrates the concern of this issue in isolation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment