What is parking in Winforms

Question

This is the next question to this question https://stackoverflow.com/a/414829/

I got the impression that the Control class does not implement the finailzer, which is really true, so leaked controls leak out forever, rather than being cleared during finalization.

Hans Passant gives some hint at the comment section, which says it is, and some ParkingWindow keyword. I googled with this keyword, cannot find any useful resource about it.

Finally, I found a class called ParkingWindow in System.Windows.Forms.Application.ParkingWindow through the decompiler, I cannot understand what is being done with it.

It seems that unscreened windows will be parified for this parking lot and subsequently destroyed, but not sure.

Question: what is ParkingWindow and what is it used for?

Edit: how does this relate to terminating or clearing a control?

Answer 1

and later destroyed, but not sure

This "not sure" is the essence of the problem. This does not happen so often when the window is not destroyed at all.

The Shawn Farka blog explains well the initial intention of the parking window. The cost of re-creating child windows was certainly higher than the list. Not the only concern, although some types of child windows are very difficult to recreate accurately. An example is TreeView, and many runtime states are associated with it. To do this accurately, you need to record the stall state of each node. It hurts and Winforms don't really do it. When you re-assign, say, the CheckBoxes or StateImageList properties, you will see that it is not.

Everything and everything, this is a good trick, but they went overboard with him. Child control not only (temporarily) ends in the parking window when the parent window is recreated, it also moves there when:

• you set the Parent property to null
• you are using a parent set of Remove / At () controls
• you are using the parent control Clear () method

In particular, the last two bullets are almost always fatal in a typical Winforms program. They are typically used when a programmer dynamically adds and removes controls at run time. The problem is that the control is again placed in the parking window, but the programmer simply forgot them there, having lost the link to the control. And they will live there forever . Until the user completes the program, because it turns into a slow molasses from creating thousands of windows. Or the program crashes with "Error creating window handle." What happens when Windows gets rough after a program has created 10,000 windows.

It is required instead Call the Dispose () method of the control. Very unusual in .NET in general, a call to Dispose () is always optional. Not in the case of the Control class, the parking window maintains a link to the control and thus prevents the finalizer from starting.

Answer 2

This is described in this article by Sean Burke of MS: Windows Forms Parking Window .

One of our goals with Windows Forms was to smooth out the weirdness of Win32 as much as we could. And one of the main oddities is window handle control (HWND) and lifetime. We certainly did not want the average user to worry about this. In In most cases, it was pretty easy. You simply collect the entire state, and then when you really need to show the window, you do the creation on demand, then you manage your state from HWND instead of your internal members.

Well, that doesn't always work so well. See, there are certain properties of Win32 windows that you cannot change when a window is created. For example, border style. Thus, in order for the user to change the style of the frame after creating the window, you need to recreate the handle. This means that you need to not only pull everything from the state you want from the existing one, but you need to recreate it and bring it back. Okay, this is not too complicated.

What about the kids? Oh fencing. Children.

If there are children in the window that you change at the border, destroying his pen will destroy the handles of all his children. Then you need to recreate them, which is very expensive. And also a little expensive.

Enter the parking window. The parking window was our solution to this problem. It was somewhere that you could “park” the HWND until you got the right parent for them. Think of it as Hunting Aid, but invisible.

So, in the case of creating a descriptor, we would check if every child is there. If this were so, we would (if necessary) create a parking Window, the parent children for this, recreate the parent descriptor, then move them back. It worked very well, although the service life of the parking window caused some problems ...