Progress.
I solved the messed-up-buttons-scrolling-with-the-listbox issue by sidestepping it. (I never did solve the problem of scrolling the listbox with the buttons attached to it as its children.) Instead, the cubbyholes are now in a static control container that's always at the top (yeah, it would be nice to make its position configurable, but too bad for that). The listbox, if there is one (assuming the config file is present and was parsed correctly) starts below it. And it all works! The listbox even scrolls correctly (try resizing the window vertically and see what happens).
Phew! I went through so many gyrations to get this to work. When I first created a static window and put the buttons inside it, they worked OK, except they had an ugly white border around them where the edge wasn't getting painted the background color of the static. I tried catching WM_CTLCOLORBTN and passing a brush the color of the background; no go. (All the while I was scouring the web for advice. Found lots of stuff on Code Project and Stack Overflow and others, but nothing that worked.)
Then I tried going the owner-draw route. Ugh. What a goddamn can of worms that is. At first I could only get the ugly pre-Vista looking buttons--remember, all square? Then I started delving into ... oh nooooooo ... themes. That's really a squirming, festering can o'worms. I was actually able to get to the same point I was before I started: buttons with the new look (no text, since I'd have to draw that myself) but still with the damned white border! And of course, to use any of the theme stuff you have to find the right DLL, use LoadLibrary() and GetProcAddress(), and then a bunch of push-push-calls because nobody ever got around to adding this stuff to our Masm32 libraries, even though it's been, what? 10-12 years ago that this stuff came out?.
Oh, and I almost forgot that at one point I was wrestling with the "theme" stuff (OpenThemeData() specifically), just couldn't get it to work at all, when it dawned on me that maybe those functions need Unicode names, not ANSI; sure enough, that was the problem.
Then I found a little something that worked: in addition to catching WM_CTLCOLORBTN, you need to catch NM_CUSTOMDRAW notifications (which is odd, since it's no longer an owner-draw control); when the dwDrawStage = CDDS_PREERASE (and the moon is in the right phase and it's a month with an "R" in it), you do a FillRect() of the button using the background color. Which fixes it. No owner-draw needed, just a little subclassing.
What a mess Win32 is ...
Anyhow, try this version out. I promise I'll start making some substantive progress soon (switching to a RichEdit control so I can add search and replace, which no self-respecting editor can be without).