This seemed to me to be a good example of what's being discussed in the 'how hard is Cocoa to learn' thread and is the kind of thing makes me pull my hair out.

If you hook things up with IB and write code you think it's quite simple, then you come to something like wanting to change the title of the document window and .. in order to do it you need to understand the way the framework makes NSWindowControllers, how that relates to the NIB you want for the document, that the NSWindowController has a method synchronizeWindowTitleWithDocumentName which needs to be overridden and that you then have to override the document method which makes the window controllers to make one of yours.

phew - it all makes sense, and Kyle that was a great explanation, but I have no idea if I'd have gotten there.

What I find with the Cocoa framework is that I know there must be a *right* way to do anything because I know the framework is well- designed and has been refined over the course of years, I know there's some perfect place in a responder chain to put that one method, or there's one method I can override which is in the exact place to tweak the behaviour I want. Finding that place instead of putting in a kludge suddenly requires 20x the depth of understanding of the entire framework. I suspect a number of people, unable to find the right place, end up sticking code in the wrong place.

I'm still reading copious amounts of cocoa documentation trying to form my mental model of what happens and when it happens and the lifecycle of applications, exactly what methods things pass through on the way, how different types of message pass down the responder chain and thus where might be a good place to look for a likely hook to do the thing I want to do. I can imagine a series of diagrams each showing a timeline of calls for one type of operation, eg opening the first window, processing a double click, opening a menu etc., currently I can just imagine the diagrams, I can't fill in the boxes.

I think this is why it takes time and effort to learn cocoa, and why people are surprised after they hook up their first application and it works .. then one day they want to do what seems trivial and hit the brick wall which requires going back to the beginning and gaining the full understanding of what the framework is doing.

.. and don't get me started on bindings :)


On May 24, 2008, at 5:13 AM, Kyle Sluder wrote:

On Fri, May 23, 2008 at 12:33 PM, vince <[EMAIL PROTECTED]> wrote:
How do I set my document based application to omit the filename reference at
the top of each opened document window?

It sounds like you need a little more education about how this works.
NSDocument has a window outlet, but the document itself doesn't manage
the window(s).  Instead, it creates one or more NSWindowController
objects.  Now, in the simple case, you override -[NSDocument
windowNibName] and NSDocument takes care of creating an
NSWindowController for you.  NSWindowController has some special logic
for dealing with document-based applications, including the method
-synchronizeWindowTitleWithDocumentName, which as its name implies is
responsible for deciding whether to replace the window title with the
result of -[NSWindowController windowTitleForDocumentDisplayName:].
By default, -[NSWindowController
synchronizeWindowTitleWithDocumentName] returns YES.  In your case,
you will want to subclass NSWindowController and override this method
to return NO.  That means that you can no longer take advantage of
NSDocument's default controller creation, of course; you will need to
instead override -[NSDocument makeWindowControllers] to instantiate
your custom window controller instead.

HTH,
--Kyle Sluder
_______________________________________________

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/rols%40rols.org

This email sent to [EMAIL PROTECTED]

_______________________________________________

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]

Reply via email to