Hacker News Reader

Comment by mark-r | Hacker News Reader

I worked on Windows apps for many years. The problem is that the Win32 interface only really gets you 90% control. The hardest thing I've ever done was when our product manager decided that color theming our app was an essential new feature. That's when you find out that certain Windows features like scroll bars under certain conditions bypass the usual message loop completely, because they know they can get away with it. The part I remember most vividly was recreating the lowly MessageBox from scratch, because none of the internals of the system supplied one were exposed in a way that you could modify them.

View on HN

My memory from the old days is you can use Win32 hooks to modify the MessageBox. HCBT_CREATEWND gets you the HWND of the MessageBox, and you can subclass it (in the Win32 sense) to insert your own WndProc. Then you're off to the races--it's your dialog now.

But it wasn't just one window, there were lots of controls on that window and the relationship between them wasn't as obvious as you'd assume. Trust me, recreating the whole thing from scratch was easier.

The fun part was making a C++ class that could build up an in-memory dialog template. You had to do it that way because it was dynamically sized based on the message you displayed and the buttons you needed. If you used the default colors, you might be able to tell they were different if you squinted but you wouldn't know which was mine and which was Microsoft's.

I've done this for real, in commercial code that shipped. No trust needed; I have personal experience. For typical minor MessageBox additions, this can be easier than rebuilding the whole dialog yourself. Sometimes, we just wanted to add a "Don't ask again" checkbox which didn't require touching the existing child windows at all. I also used this technique to simply change the labels on the buttons to custom text. I had a MessageBox wrapper that accepted a list of button strings instead of a predefined constant. We've all built various custom message boxes, of course, but not every situation required that level of effort.

These days you can just use a TaskDialog, of course, and it's way more flexible than MessageBox. But it's fun to remember the old techniques.

You can modify this stuff if you go deep enough and are willing to detour the native Win32 API functions. Some things implemented in User32.dll don't make the appropriate API calls back to other User32.dll functions, and you need to detour Win32U.dll instead.

Wow this could be painful, to try to recreate something from scratch. Would QT make it work?

It was more of you had to know where to grab control. It was not always clear.

With some of them it was dead easy and you can do it on window creation.

Others you had to hook it out by playing with the window params (SetWindowLong) and getting the underlying control and then changing it.

Some controls had their own bespoke way where you would send messages to the control then it would take care of it.

Some you would have to iterate over the control list that window controlled and change it.

In some cases it was just such a pain you were better off making your own custom control window that was just a mashup of other controls that you could control.

It was one part experimentation and one part reading the docs (if the control had it). Now if it was a built in windows control you were playing with. You had to take on the risk on windows version update the customization you did would break if you did non documented things.

The biggest problem was when there was an established protocol, but it wasn't always followed. I remember scroll bars being the worst. Usually you could respond to the messages and everything would work the way you want, but there were some edge cases where Windows would update those scroll bars without even telling you it was doing so. And of course it would paint those updates in the default colors.

I honestly don't know if Qt would have made it any easier. But this was a large and old app that relied on Win32 at its core, and nobody was going to accept rewriting it for just one feature. Plus our customers were very time sensitive, and anything that could have slowed it down by a few ms was off the table.

Reply on news.ycombinator.com