Destroying the menu.. when?

[Edwin Knoppert]

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?

[Michael Mattias]

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.

[Edwin Knoppert]

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?

[Michael Mattias]

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 ...

    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

[Edwin Knoppert]

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.