RE: Documentation frustrations
RE: Documentation frustrations
- Subject: RE: Documentation frustrations
- From: Jeff Laing <email@hidden>
- Date: Mon, 11 Jul 2005 11:34:00 +1000
> Though I'd also add "why" there; the issue
> with a good bunch of the docs (at least as of 10.3 -- a lot has
> already improved in the current batch) was that they *either*
> contained "what" or "how" descriptions. We need both. And we need
> "why". And in addition, we also need more information on what
> certain methods don't do, or shouldn't be used for and what routines to
use
> instead. As in:
Sorry about being late to this gripe-fest, but thought I'd add two cents
worth, AND an exercise for the students.
After moaning last week about the hidden "by the way, NSDrawers just don't
work" in the release notes, I started doing what had been suggested earlier
to use a floating toolbar instead. And suddenly all my problems went away.
That is, until I tried to keep the state of the toolbar reflecting the
frontmost document. The exercise for the search experts to tell me the
keywords that I should use to locate the appropriate notification(s) that
let me do this.
If you use the windowBecameMain (or whatever its called), then you can do
most of it. But apparently this doesn't arrive when your application goes
from background to foreground. "No problem" says Jeff, "look at the
application notifications instead". Hmmm, now how do we work out what the
current document is? Look at the shared document controller? Nope, that
returns nil as the current document.
My guess is that the application notifications arrive BEFORE the
window/document hierarchy has reestablished itself. Doesn't make any sense
to me at all, since I figure that front-to-back window order should remain
the same when the app is in the background - all I can observe is that the
current document isn't available when the "came-forward" notification
arrives.
Thus, I think the documentation, at least on notifications, also needs to
describe WHEN in greater detail.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden