MFC dialog shows in task bar

0
votes

I have an application that uses dialogs from two DLLs. The code for the dialogs in the two DLLs is almost identical:

  1. Both dialogs have the same style in the RC file: DS_SETFONT | DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU.
  2. Both dialogs are shown using ShowWindow(SW_SHOW).
  3. Both dialogs are created on demand and not when the application starts.
  4. Both dialogs have a NULL parent.
  5. Both dialogs inherit from CDialog.

The only differences are that:

  1. In dialog A, AFX_MANAGE_STATE() is called before the dialog constructor, where as for dialog B it is called at the start of the constructor.

I don't see that any of these differences should make any difference and yet, when I show the dialogs, dialog A does NOT have an icon in the task bar and dialog B, and furthermore, bringing the main window to the front brings dialog A to the front (and visa versa) whereas dialog B behaves independently.

I want to make dialog B behave like dialog A. Can anyone tell me why this difference of behaviour is there and how to fix it so that dialog B behaves the same as A?

I know you would love sample code, but that would take some time (which I don't have) to craft. The existing code is all company commercial and also a huge app from which extracting the key parts would be very difficult indeed.

** UPDATE ** If I call ::AfxGetMainWnd() in dialog B's contrustor before I call AFX_MANAGE_STATE() I can get a pointer to the main window's pointer. Yay! When I then pass it to Create(), the program crashes. Boo!

It looks like I cannot set the main window as the owner of dialog B, which I think would solve my problem, presumably because dialog B is in a DLL. What I don't understand is why this works for dialog A.

1
mfcdialogtaskbarnon-modal
To diagnose your problem, you need to learn what 'modules' are, and how MFC module state implementation works. Your proposed answer doesn't address the real issue. - IInspectable
It might be better if this comment was attached to my answer not the question. I read that article and am no wiser now than I was before. It does not say anything about windows of any sort and nothing as to why you need to have a CWinApp instance for DLL dialogs to be correctly owned by the main application. I am guessing that when you instantiate CWinApp in a DLL, it identifies a singleton application object belonging to the main application process and connects itself to that, and all dialogs then created look for a CWinApp in the current module at creation and set it as their owner. - AlastairG
Thus the dialogs do not need a taskbar icon and when you bring the main application window to the front, the dialog windows come to the front too. What do you consider to be the "real" issue that my answer does not address? As far as I can tell from my investigations it is purely and simply that the dialogs have nothing within the current module context to parent to, and adding a CWinApp instance, as per my answer, solves that. - AlastairG

1 Answers

-1
votes

The DLL that implements dialog A instantiates an instance of CWinApp. The DLL that implements dialog B doesn't.

To fix this simply add the following line to a CPP file, possibly a standalone "the_app.cpp" file:

CWinApp dummy;

I.e. "the_app.cpp":

#include "stdafx.h"

CWinApp dummy;