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.
Announcement
Collapse
No announcement yet.
Destroying the menu.. when?
Collapse
X
-
So i guess that when a dialogtemplate is used this would be the only case the menu destruction is handled by Windows?
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 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.
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
Leave a comment:
-
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?
Leave a comment:
-
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.
Leave a comment:
-
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?Tags: None
Leave a comment: