Two items:

[list type=decimal]

There are no default images for the toggle selections... oops!

Are you sure you want to put a default button on the title bar after installing? Do you default to multi-monitor task bars being on? This change feels obtrusive, IMHO. The buttons also have previous discussed issues that make DF look (pardon me for saying this) amateurish where everything else looks professional. I would suggest, at least, a poll on the issue.

[/ul]

sfwrtr, could you go into more detail about the "previous discussed" button issues? From what I see they look professional, are rock solid and have no lag.

On having a button go up by default: I think this is toggled if you turn the multi-taskbar on and also is to show most people (who may never go into settings) that there are buttons available. I suppose Jon could pop up a dialog box on installation (or first run) that shows the buttons in place and how to turn them on....)

Sorry to use a loaded word, but I am also a writer (i.e., sf - writer) and it did get your attention.

First off, your product is professional grade, no questions there. And so far as I can tell, there is nothing that you can do to make titlebar buttons perfect because of Windows limitations. Whilst they work well most of the time, the buttons are not actually part of the UI. That you made them appear non-MS is brilliant; there is no confusion that MS had something to do with it Unfortunately, because they aren't generated by the UI, they appear a fraction of a second after the Window is shown. They disappear a fraction of a second after the Window disappears, is minimized, or maximized. If you are running a wierd UI vendor's program, like Adobe CS4, they highlight how out-of-spec they are (i.e., both Adobe and DF's titlebar buttons). And if the CPU is pegged (or even above 50%), you get a mouse-tails (or rather a button-tails) affect when you move any Window. The user is not expecting any of this behavior.

This is no defect of your program or design so far as I can tell. The problem is I know this, but most of your audience, i.e., the programming-muggles, haven't a clue. The result is, well, it doesn't look good....

I hope that explains what I meant and why I advised against defaulting them to on, and why I suggested a warning label to explain the behavior.

And I do use the titlebar buttons, now that I am used to them. (And, oh yes, thanks for the clarification above - that makes perfect sense).

You're welcome.

Too bad you can't nab that WM_NCPAINT message! I totally understand there are things you just can't do. On my machine, I'd say response is actually about 50ms (1/30th of a second), but I can still see movement.

Even as a high priority process, the buttons still don't stay put nor do they appear/disappear faster. I wanted to demonstrate this using video screen capture, but that will be the subject of a different post. That said, it will probably help when the CPU utilization is high.

Its probably as good as it gets. Not making it a default behavior was a good idea.

Yeah, and watch CS3 and CS4 when they crash. They both loose that custom window and default back to a standard Window's frame and titlebar. So even they are tacking their GUI on top of what's already there. You can't code to that.

Hmm... I guess I'll have to peg the CPU with CS4 running and not maximized (do a unsharp mask or something), and shake the window like a rag doll for grins. I'd wager that'll make UI GUI pieces of non-standard stuff wobble.