weiss@theory.lcs.mit.edu (Paul G. Weiss) (04/13/90)
The sample application MDI shipped with the developer's kit contains something that has been mystifying me. In order to make the system menu and minmax button of document windows disappear when they are deactivated the parent of these windows is set to HWND_OBJECT when deactivated and to the document frame window when reactivated. So far, so good. What is puzzling is that the document frame window procedure handles WM_DESTROY by setting the parent of these windows back to the frame with a comment saying that this is necessary to insure that they are destroyed. But is it really necessary? These windows are still OWNED by the frame window even though they are no longer children and according to the documentation, owned windows should automatically be destroyed. With this in mind I decided to remove the two calls to WinSetParent from the code and lo and behold, I get a RIP on the debugging terminal saying that a window has not been destroyed and then another one complaining of an invalid heap handle. Can anyone explain this? -Puzzled
smeans@microsoft.UUCP (Scott MEANS) (04/15/90)
In article <WEISS.90Apr13105430@toucan.lcs.mit.edu> weiss@theory.lcs.mit.edu (Paul G. Weiss) writes: > >What is puzzling is that the document frame window procedure handles >WM_DESTROY by setting the parent of these windows back to the frame >with a comment saying that this is necessary to insure that they are >destroyed. But is it really necessary? These windows are still OWNED >by the frame window even though they are no longer children and according >to the documentation, owned windows should automatically be destroyed. > >With this in mind I decided to remove the two calls to WinSetParent from >the code and lo and behold, I get a RIP on the debugging terminal saying >that a window has not been destroyed and then another one complaining of >an invalid heap handle. When a window is destroyed, all of it's children are destroyed recursively before it is freed but then rather than destroying the owned windows their owner is set to null. This means those frame controls that are on the object window when the frame is destroyed hang around until your app terminates. Since the frame controls depend on certain resources allocated by the frame window, when they are destroyed they try to reference things that no longer exist (like the frame heap). Poof! If the documentation states that both owned windows and child windows are destroyed when the parent/owner dies it is incorrect. -- /\/\ //\/\\ \> </ S/ \eans