I’ve been doing some research around component models for Silverlight. Since Silverlight brings us back to a client side programming model (yay member variables!), I started cruising through the Windows Forms source looking at some of the things we did back then as a way to remind myself of some of the subtleties of working in that space. I’m looking for those things that you don’t usually think of until you’re about 75% done with coding then realize you didn’t plan for it.
Anyway, since I worked on Windows Forms for the better part of 7 years, it’s a bit nostalgic cruising through some of this code. Just like how when you open your old high school yearbook and see someones picture and go “wow, I haven’t even thought of that person in years”, I came across a Windows-Forms-ism called…
The Parking Window.
The Parking Wha? Yes, the Parking Window.
One of our goals with Windows Forms was try to smooth out as much of the oddity of Win32 as we could. And one of the principal oddities is that of window handle (HWND) management and lifetime. We certainly didn’t want the average user to need to worry about this stuff. In most cases, it was pretty easy. You just gather up all of the state, and then when you actually need to show the window, you do the creation on demand, then you drive your state off the HWND instead of your internal members.
Well, this doesn’t always work so well. See, there are certain properties of Win32 windows that you can’t change once the window is created. Like the style of the border, for example. So to allow a user to change the border style after the window has been created, you need to recreate the handle. Which means you need to not only pull all of the state out you want out of the existing one, but you need to recreate it and push it back in. Okay, that’s not too hard.
But what about the children? Oh, fiddlesticks. The kids.
If the window you’re modifying the border on has children, destroying its handle will destroy the handles of all of its children as well. Then you need to recreate them, which is very expensive. And expensive is bad.
Enter the Parking Window. The Parking Window was our solution to this problem. It was somewhere that you could “park” HWNDs until you have a fitting parent for them. Think of it as Window Handle Foster Care, but invisible.
So in the case of a handle-recreate, we’d check to see if there were any children. If there were, we’d (if needed) create the Parking Window, parent the children to that, recreate the parent’s handle, then move them back over. Worked pretty well, though managing the lifetime of the Parking Window did cause some problems…