🚀 go-pugleaf

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