WTL 7.5 fixes?

[clev]

flattabctrl.h:
LRESULT onReallyClose(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& /*bHandled*/) {
MDIDestroy(m_hWnd);
return 0;
}

LRESULT onClose(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& /*bHandled */) {
PostMessage(WM_REALLY_CLOSE);
return 0;
}

MDI WINDOWs:
-onClose>
m_hMenu = NULL;
MDIDestroy(m_hWnd);

Why to add specialy MDIDestroy?
why m_hMenu is NULLed? Isnt it destroyed at the same time MDI window is destroyed?
maybe I am too lame :)

[GargoyleMT]

Yes, the menu bar is destroyed at the same time the window is closed. However, the menu is only created once - in WinUtil::init(). Before the change, once you closed a MDI window, your menus stopped working.

If you have a more elegant solution, by all means...


(ps. check out the bbcode, it would make your posts more readable.)

[clev]

Why to add specialy MDIDestroy?

- which means that MDIDestroy is actually called twice and probably m_hMenu = NULL; should be in the

onReallyClose

too, which is probably called every time the window is closed as the last thing (Maybe?<-the thing which I ask :]; destroy is called before posted message WM_REALLY_CLOSE).
I hope this is clean to understand :).
btw watch flatbarctrl.h and the place onClose I mean
btw BBCode sux with that stupid formatting :)

However, the menu is only created once - in WinUtil::init().

- I shouldnt find there some MDI menus create..
flattabctrl.h, but I found it here ;)

Code: Select all

HWND Create(HWND hWndParent, ATL::_U_RECT rect = NULL, LPCTSTR szWindowName = NULL,
   DWORD dwStyle = 0, DWORD dwExStyle = 0,
   UINT nMenuID = 0, LPVOID lpCreateParam = NULL)
{
...
m_hMenu = ::LoadMenu(ATL::_AtlBaseModule.GetResourceInstance(), MAKEINTRESOURCE(nMenuID));
...
}

[GargoyleMT]

I hope this is clean to understand .

No, it's totally unclear. Certainly, wtl 7.5 destroys m_hMenu if it's non-NULL. Where the best place to put it is totally irrelevant. To some extent, MDIDestroy() is as well - though it doesn't seem to call itself, and WM_MDIDESTROY doesn't seem to get posted on its own either.

- I shouldnt find there some MDI menus create..
flattabctrl.h, but I found it here

Okay...

Code: Select all

   CMenuHandle file;
   file.CreatePopupMenu();

   file.AppendMenu(MF_STRING, IDC_OPEN_FILE_LIST, CSTRING(MENU_OPEN_FILE_LIST));
   file.AppendMenu(MF_STRING, IDC_REFRESH_FILE_LIST, CSTRING(MENU_REFRESH_FILE_LIST));
   file.AppendMenu(MF_STRING, IDC_OPEN_DOWNLOADS, CSTRING(MENU_OPEN_DOWNLOADS_DIR));
   file.AppendMenu(MF_SEPARATOR, 0, (LPCTSTR)NULL);
   file.AppendMenu(MF_STRING, IDC_FOLLOW, CSTRING(MENU_FOLLOW_REDIRECT));
   file.AppendMenu(MF_STRING, ID_FILE_RECONNECT, CSTRING(MENU_RECONNECT));
   file.AppendMenu(MF_SEPARATOR, 0, (LPCTSTR)NULL);
   file.AppendMenu(MF_STRING, IDC_IMPORT_QUEUE, CSTRING(MENU_IMPORT_QUEUE));
   file.AppendMenu(MF_STRING, ID_FILE_SETTINGS, CSTRING(MENU_SETTINGS));
   file.AppendMenu(MF_SEPARATOR, 0, (LPCTSTR)NULL);
   file.AppendMenu(MF_STRING, ID_APP_EXIT, CSTRING(MENU_EXIT));

Follow MainFrm.cpp, and you'll see how the menus get propagated to the various MDI client windows... This is done so they show up and register themselves properly in the "Window" menu.

Code: Select all

m_hMenu = ::LoadMenu(ATL::_AtlBaseModule.GetResourceInstance(), MAKEINTRESOURCE(nMenuID));

DC++ doesn't use this form of loading/making menus, most likely because it goes against the method of localization that was decided (to allow users to contribute their own translations, instead of them being hardcoded into the program).

[clev]

Uff, I will try to be more clear..
file windows/flattabctrl.h

Code: Select all

class ATL_NO_VTABLE MDITabChildWindowImpl
{
...
   LRESULT onDestroy(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& bHandled) {
      m_hMenu = NULL; // <-HERE
      bHandled = FALSE;
      dcassert(getTab());
      getTab()->removeTab(m_hWnd);

      BOOL bMaximized = FALSE;
      if(::SendMessage(m_hWndMDIClient, WM_MDIGETACTIVE, 0, (LPARAM)&bMaximized) != NULL)
         SettingsManager::getInstance()->set(SettingsManager::MDI_MAXIMIZED, (bMaximized>0));

      return 0;
   }

   LRESULT onReallyClose(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& bHandled) {
      MDIDestroy(m_hWnd);
      return 0;
   }

   LRESULT onClose(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& bHandled) {
      PostMessage(WM_REALLY_CLOSE);
      return 0;
   }
...
}

fix it for all MDI frames and is more clean then it is at current CVS..
or another solution is change it in the wtl removing that code, beside it looks like unofficial changes - only some fixes. no future support...
OK?

[arnetheduck]

probably makes sense, make a patch and send it to gargoylemt =)

[clev]

I thing, it is easy to change it.. diff for one line, blah ;)

[arnetheduck]

it should probably be removed from all other files tho, which is tedious and boring work.

[clev]

U are right.. so Garg, go and clean it >:-)
I recommend to search mdidestroy(m_hWnd); on entire solution, resp. dcplusplus project ;)

[GargoyleMT]

I'll change my patches, and send a better one off.

[GargoyleMT]

it should probably be removed from all other files tho, which is tedious and boring work.

Well, so my only changes in the patch were to move the m_hMenu setting (and conditional nulling) into the base class, and remove it from all the windows. It wasn't too bad, and it's set up so if someone starts using the menus in the resource manager, it shouldn't lead to a memory leak when closing and reopening windows...

Thanks for the idea, clev.

[clev]

When I did search for onclose( and want to add there MDIDestroy - as was on the CVS, I found that flattabctrl and postmessage(really close) - so I said to me, that something is strange, so I create account and post a message, thx for reactions..