Process "PluginPrefPage" with MFC's CWnd!

[shaohao]

Hi, Paul:
Any idea about how to process "PluginPrefPage" with MFC's CWnd.
I create a PluginPrefPage like this:

PluginPrefPage prefPage;
prefPage.struct_size = sizeof(prefPage);
prefPage.hModule = hInstance;
prefPage.hModuleParent = 0;
prefPage.lpTemplate = MAKEINTRESOURCEW(IDD_CONFIGURE);
prefPage.lpDisplayText = L"CLI Encoder";
prefPage.lpDialogFunc = ConfigDlgProc;
prefPage.nCategory = PREFPAGE_CATEGORY_ENCODEFORMAT;
prefPageID = QCDCallbacks->Service(opSetPluginPage, &prefPage, 0, 0);


But I make my plug-in with MFC and want to process the dialog "IDD_CONFIGURE" with MFC's CWnd.
Can you give me any hint?

[Paul]

Sorry, I don't know MFC (Macro obFuscated Code).
Is there a way to get the WndProc out of the CWnd? If so, try passing that in to the PluginPrefPage.

[shaohao]

MFC = Microsoft Foundation Classes
Which is used in VC++

Wish I could get the WndProc or make CWnd attach to the PluginPrefPage HWND.

[Paul]

MFC = Microsoft Foundation Classes
That's what MS calls it, but MFC is really just one big fat ugly macro. ;)

I'd actually like to find out the answer to this issue. I'd like for plugins to be easily made in any language.

[Equinoxe]

I have done quite a bit of MFC work in the past and was recently thinking of building a new "scheduler" plugin in MFC as an alternative to the current Timer plugin. (Thanks Paul for the Timer sources). I had attempted to get MFC hooked up to QCD for creating the preference page, but have failed to get all the needs of MFC met with my wrappers and hacks. It was getting just too ugly so I put it aside. I then recently stumbled on this note and thought I'd see if you were really serious about MFC support in QCD/QMD. So here goes...

If I am guessing correctly, the main reason for supplying the WndProc and TemplateID to QCD is for its invoking CreateDialog (QCD calls CreateDialogIndirectParam?) inside the opShowPluginPage Service call. However, for MFC dialogs to function at all, dialog creation must be done within the MFC framework. Otherwise, it seems nearly impossible to "hook-up" MFC to the QCD Dialog creation process. I've tried - the dialog renders, but no OnInitDialog or OnActivate callbacks happened.

Somehow, the PluginPrefPage structure would need to indicate to QCD this is an MFC plugin.

For Dialog creation, the MFC plugin could still provide you with a TemplateID and a WndProc (returned by AfxGetAfxWndProc()) if necessary. It's just the window creation and dialog init that MFC needs to do. If QCD could call the plugin to create the dialog and receive a hWnd back, would
that be sufficient?

Additionally, in order to get keyboard shortcuts & accelerators working, a MFC plugin with a preference page dialog opened will need to get "PreTranslate" callback events from QCD's message dispatcher.

Questions:
- Do you need the WndProc for anything other than dialog creation?
- Are you using a windows creation hook?
- Would you still need the dialog TemplateID in this case too? Is this manipulated by skins?
- Do you think this has a chance to work?

Thanks for listening, /ted

[Paul]

Additionally, in order to get keyboard shortcuts & accelerators working, a MFC plugin with a preference page dialog opened will need to get "PreTranslate" callback events from QCD's message dispatcher.
Eeek. This may forclose adopting the current method of dialog hosting.

The WndProc and TemplateID are indeed just used for dialog creation. Not using a windows creation hook.

Do I think there is a way to may this work? Hmm...
Not in the current version it seems. I could create a new op where you just pass in a pre-created HWND to a dialog. That way you can control how it is created as well as the message pump for it should you want to. Would that suffice, or do you see other pitfalls with MFC, or perhaps another solution?

[Paul]

Can you explain why in MFC you couldnt pass in a WNDPROC as required then just manually set the message map to translate message like WM_INITIDIALOG to call OnInitDialog()?

[Equinoxe]

To answer you last question first:

MFC wants to do a bunch of work before the Window is created. When one calls CDialog::Create, MFC installs a CBT filter hook before calling CreateWindowEX. It supplies CreateWindowEx with a special WndProc that waits for HCBT_CREATEWND. It then does a number of pre-window creation operations which allow the application/DLL to override CTL3D (CommonControls) functionality. It essentially is insuring that the subclassing of CTL3D messages is handled in the correct order. After doing the init processing and dispatching OnInitDialog, it then replaces the WndProc with the normal AfxWndProc message map dispatcher. While one can certainly get OnInitDialog dispatched with a private WndProc wrapper, you cannot get any CommonControls subclassing to operate correctly. Essentially, it's messing with the windows class registration order.

There's a good description of this in "MFC Internals" by George Shapherd & Scot Wingo - "How MFC Windows Become Wired to a WndProc".

Bottom line - we need to call the MFC flavor of CreateDialog for all this to work.

More on this later, I'm heading out for a long weekend - will be back on Monday. Thanks for listening.

/ted