Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Does DestroyWindow Parent CDialog destroy all ChildControls

Does DestroyWindow Parent CDialog destroy all ChildControls

Scheduled Pinned Locked Moved C / C++ / MFC
7 Posts 4 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • F Offline
    F Offline
    ForNow
    wrote on last edited by
    #1

    Hi I have a CDialog which I created on the heap along the way I create a Richedit and a number of other controls When the users hits X in the right hand corner I Destroy the CDialog do I have to DestroyWindow the rich edit and child controls as well

    L L 2 Replies Last reply
    0
    • F ForNow

      Hi I have a CDialog which I created on the heap along the way I create a Richedit and a number of other controls When the users hits X in the right hand corner I Destroy the CDialog do I have to DestroyWindow the rich edit and child controls as well

      L Offline
      L Offline
      Lost User
      wrote on last edited by
      #2

      See DestroyWindow function (Windows)[^].

      F 1 Reply Last reply
      0
      • F ForNow

        Hi I have a CDialog which I created on the heap along the way I create a Richedit and a number of other controls When the users hits X in the right hand corner I Destroy the CDialog do I have to DestroyWindow the rich edit and child controls as well

        L Offline
        L Offline
        leon de boer
        wrote on last edited by
        #3

        No, Richard gave you the link all child windows are automatically disposed. Your only responsibility is to cleanup any memory allocation, handles etc you specifically created. You do that by intercepting the WM_DESTROY message and cleaning up there. WM_DESTROY is sent just before the window is deleted but while the window is actually still valid. Typically you create things in the WM_CREATE and you dispose of it in the WM_DESTROY.

        In vino veritas

        F 1 Reply Last reply
        0
        • L Lost User

          See DestroyWindow function (Windows)[^].

          F Offline
          F Offline
          ForNow
          wrote on last edited by
          #4

          Sorry :( Didn't see this

          Quote:

          The function first destroys child or owned windows, and then it destroys the parent or owner window

          1 Reply Last reply
          0
          • L leon de boer

            No, Richard gave you the link all child windows are automatically disposed. Your only responsibility is to cleanup any memory allocation, handles etc you specifically created. You do that by intercepting the WM_DESTROY message and cleaning up there. WM_DESTROY is sent just before the window is deleted but while the window is actually still valid. Typically you create things in the WM_CREATE and you dispose of it in the WM_DESTROY.

            In vino veritas

            F Offline
            F Offline
            ForNow
            wrote on last edited by
            #5

            So If I do a "new" for an object which I later create a child or my case rich edit I have to delete the object after the DestroyWindow which destroys the Parent CDialog and child controls Thanks

            P L 2 Replies Last reply
            0
            • F ForNow

              So If I do a "new" for an object which I later create a child or my case rich edit I have to delete the object after the DestroyWindow which destroys the Parent CDialog and child controls Thanks

              P Offline
              P Offline
              Parthiban Appuswamy
              wrote on last edited by
              #6

              Yes, if you are allocating memory using 'new' to your RichEdit, then yes you have to release it. But you have to do it before your parent window (in this case your CDialog) is destroyed. Override OnDestroy (WM_DESTROY) and destroy your RichEdit followed by 'delete' (to release heap memory) and then call the CDialog::OnDestroy().

              1 Reply Last reply
              0
              • F ForNow

                So If I do a "new" for an object which I later create a child or my case rich edit I have to delete the object after the DestroyWindow which destroys the Parent CDialog and child controls Thanks

                L Offline
                L Offline
                leon de boer
                wrote on last edited by
                #7

                Okay the rules with memory or object allocation and deleting are very simple. Situation 1: If the memory/object is used by multiple children windows and/or the parent then you create it in OnCreate (WM_CREATE) on the parent and destroy it on OnDestroy (WM_DESTROY) of the parent. The reason is because multiple children and/or parent are using it and you need it created before any children and disposed of after the children are deleted. Situation 2: If the memory/Object is used by ONLY the SINGLE child window EXCLUSIVELY (that is the data belongs really to the child) then you create it on OnCreate (WM_CREATE) of the child and you delete it with the OnDestroy (WM_DESTROY) of the child. Sometimes people get lazy and just use situation 1 to cover situation 2 but there are traps in that. It is very easy to forget you need something done before the child is created which is in an unrelated block of code in the parent window create function. So generally I would advise against being lazy and using situation 1 to try and cover all situations. Using Situation 2 when it is valid to do so makes your code self contained portable without thinking about it. Situation 2 is that most often not understood by people. I will give you a simple example I might use on your edit entry, and this is a subclass of the edit I use a lot in programs. OnCreate (WM_CREATE) of the edit box I create a string object. Whenever the user hits enter, I validate the entry via a message call and if its valid put the current value into the string object and then update the edit window to the new value. Why do this ... well because in the edit box handler hitting the "esc" key goes and gets the value from the string object and puts it back it the edit box. It is a return to last valid value function or a simple single step back. If you think about it you could extend the concept to a list and be able to scroll back thru the list of entered values something you might recognize for the entry address input of your web browser. Now the point here is the string object is the edit boxes responsibility to delete so it will do that on it's OnDestroy (WM_DESTROY). Now everything is self contained I can create as many of these edit boxes as I want into a parent and they all look after there own object string. So basically you need to work out what data is being used where and in this regard it is very similar to thread or task code.

                In vino veritas

                1 Reply Last reply
                0
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                • Login

                • Don't have an account? Register

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • World
                • Users
                • Groups