True story: It's 1986 or so, and I'm writing a lot for PC Magazine and Executive Editor Paul Somerson tells me they need a sidebar about OS/2 for a feature story they're doing. He wants an "everything you need to know about OS/2" piece, including all the new features, benefits over DOS, what it means for the programmer, what it means for the user, etc, etc. And then he asks: "Can you do it in 250 words?"
Which brings me to the second rule I've set for myself when writing my Windows Presentation Foundation book:
Rule 2. Forget About Comprehensiveness.
Of course, there's a definite satisfaction in writing a book that basically covers the whole thing. The very early editions of Programming Windows almost managed that feat. (The first edition didn't cover the comm interface or the music interface, but the music interface wasn't MIDI and I never encountered any hardware that ran off it.) I also attempted to be comprehensive in my first Windows Forms book, Programming Microsoft Windows with C#. Of course, I wasn't. I only managed to be thorough by ignoring anything that had the word "data" connected with it, under the assumption that "data" stuff was for people focusing on System.Data. That was a big mistake. But I'm pretty sure the book has comprehensive graphics coverage.
WPF is huge. (Consider how long they've been working on it.) Attempting to write a book — even a thousand page book — that covers everything in WPF is futile. By recognizing early on that it's impossible, I've achieved a certain serenity and freedom. I don't need to touch on every property in every class. I can approach the subject in a looser manner and focus more on concepts rather than details.
Sometimes the reader doesn't need a lot of explanation. Sometimes the reader just needs to know what .NET namespace to investigate.
What is that old saying? Teach a person how to fish through the documentation and you've fed them for life?