Announcement

Collapse
No announcement yet.

Destroying the menu.. when?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Destroying the menu.. when?

    Hmm, it seems if you created a menu from code you'll have to destroy it when no longer need it but only if not set to a window.
    This is odd since about anything dynamically set by the programmer must be destroyed manually, font's, icon's etc...

    Am i wrong?
    Is the menu an exception?
    hellobasic

  • #2
    No, you're not wrong: Thou shalt destroy what thou wouldst create.

    If thou wouldst CreateMenu() then thou shalt DestroyMenu().

    It's just that you can't destroy anything which is still in use... and if you 'SetMenu hWnd, hMenu' , the menu is in use and can't be destroyed (without something bad happening).

    But like all objects, if you DON'T destroy/release/free/close, Windows will be your mama and clean up after you when the process in which the object was created ends.
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      So in fact my code is wrong all this long, since i add the menu's by code..?

      So i guess that when a dialogtemplate is used this would be the only case the menu destruction is handled by Windows?
      hellobasic

      Comment


      • #4
        So i guess that when a dialogtemplate is used this would be the only case the menu destruction is handled by Windows?
        Assuming: Dialog is created using one of the "dialog" functions

        I'm not sure about that, but that would be my guess.

        Let's see what the SDK has to say about window destruction....
        The DestroyWindow function destroys the specified window. The function sends WM_DESTROY and WM_NCDESTROY messages to the window to deactivate it and remove the keyboard focus from it. The function also destroys the window's menu, flushes the thread message queue, destroys timers, removes clipboard ownership, and breaks the clipboard viewer chain (if the window is at the top of the viewer chain).
        So I guess if you use 'DestroyWindow' on either a regular (CreateWindowEx) or modeless dialog (CreateDialog[Indirect][Param]) window, Windows handles it for you and you are excused from the normal obligation to explicitly destroy what you create.

        So let's see what we can find re the modal calls, DialogBox[Indirect][Param], shall we?
        EndDialog does not destroy the dialog box immediately. Instead, it sets a flag and allows the dialog box procedure to return control to the system. The system checks the flag before attempting to retrieve the next message from the application queue. If the flag is set, the system ends the message loop, destroys the dialog box, and uses the value in nResult as the return value from the function that created the dialog box.
        Hmm, if Windows internally calls DestroyWindow to "destroy the dialog box" then I guess you don't have to destroy any attached menus explictly in this case, either.

        That's easy enough to test ...

        Code:
            hMenu = CreateMenu .....
        
            iRet  = DialogBox  ....... CODEPTR(DialogProc) 
        
            GetMenuItemInfo  hMenu 
                 Do you get info or did you get an invalid handle error? 
        
        
        
        
        FUNCTION DialogProc ...
        
                WM_INITDIALOG 
                      SetMenu hWnd, hMenu created in WinMain
        
        
                WM_Something
                    EndDialog hWNd,  iret 
        
        ...

        For at least anything other than a Modal dialog, it looks like my first guess was incorrect. Learn something every day.

        And depending on the results of above test, my guess could also be incorrect for modal dialogs.

        I have no clue how "DDT" handles its menus.

        MCM
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          You see?
          it's a different thing.
          I mean setting a fonthandle never implies it will be destroyed when the control is destroyed.

          Maybe it is done since you'll (almost) never share a menuhandle between windows.
          But i suspect this is simply by design, a choice to not have to delete a trivial handle like the menu is.
          hellobasic

          Comment

          Working...
          X