Re: Removing the Filename flag in Doc. based Application
Re: Removing the Filename flag in Doc. based Application
- Subject: Re: Removing the Filename flag in Doc. based Application
- From: Roland King <email@hidden>
- Date: Sat, 24 May 2008 11:06:36 +0800
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@hidden> 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 (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden