다음을 통해 공유

Flashback: Windows Forms Parking Window

  • 아티클

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...

Good times.

Comments

  • Anonymous
    June 20, 2007
    What fun. Myself and anyone using Windows Forms for an extended period of time, or just making heavy use of it, have received countless exceptions somehow relating to this mysterious "parkingwindow" lurking in the background. Debugging problems that cropped up citing the "parkingwindow" means heavy use of Reflector because nobody outside of Microsoft can step into the winforms code. I don't suppose you ever succeeded in getting anyone to think about releasing that code. I know you've moved on, but believe it or not, there are thousands of people out there still struggling with the quirkiness of windows forms on a daily basis. Of course, we now have a whole load more quirks in the vast WPF api to play with. Tim Dawson Divelements Limited

  • Anonymous
    June 21, 2007
    Believe it or not...still workin on it...

  • Anonymous
    July 03, 2007
    Unfortunately, Windows Forms Parking Window has been a bit of a pain for me during debugging. The first application in which I encountered it, it was stealing input focus. I hadn't dealt with that completely before it started appearing in the task bar. Frustrating times. shivers

  • Anonymous
    July 11, 2007
    Hmm - that's concerning.  I'd like to see a repro of that.  Given that it's invisible, it does seem troubling that it's stealing focus.

  • Anonymous
    July 23, 2007
    Hi, I also have a repro of such a problem - parking window stealing focus after an MDI child form closes. I've read somewhere, that this could be caused by not disposing the form correctly. Which could be the case, but it is quite a problem to debug this.

  • Anonymous
    October 16, 2008
    Good explanation. Comment about the year-book made me think of programming unix systems in C and using the "CURSES LIBRARY" UGH1 SIGH! OOHHHHHH!!!! Reason for search was that I installed Silverlight Monday and now system locks up a lot for no known reason and when i reboot I usually see about 4 or 5 Windows Forms Parking Windows pop up and then go away ... a couple of times I had to manually end the Form.

  • Anonymous
    October 17, 2008
    The comment has been removed