I have two projects: one MFC .exe and an MFC .dll. I have an MFC dialog defined in a DLL. It has a resource associated to it and it also has a class CToolboxDiag derived from CDialog.
The dialog has a simple button that shows a message dialog when clicked.
void CToolboxDiag::OnBnClickedButton()
{
MessageBox(_T("Test"), _T("T"));
}
I can export the resource from the DLL to my code, and create a standard CDialog with the correct appearance using the following code:
CDialog *diag = new CDialog;
HINSTANCE hClientResources = AfxGetResourceHandle();
//Tell the client to use the .DLL's resources
AfxSetResourceHandle(dll);
// resource_id is the resource_id in the DLL
diag->Create(resource_id, NULL);
//Restore the client application resource handle
AfxSetResourceHandle(hClientResources);
But this only results in the dialog showing up but the controls (i.e. the button) performs no action when clicked, as it doesn't have the linkage to the CToolboxDiag definition in the .exe.
I wanted to export the dialog (with the button code) without having to export the class definition to the .exe. In other words, I want to export a fully functional dialog, including its buttons actions, without having the CToolboxDialog definition on my .exe, so that this can be fully modular. How could I do this?
This can't work in this way. The resource template has no direct connection to your code in the DLL. Your code just created an "empty" CDialog class that has no handlers hat all, expect the default handlers (OnOk, OnClose...)
So you need to create the object CToolboxDiag and this has to happen wehere the dialog code is located. This is inside the DLL.
The easiest way is to export a function that just creates the dialog inside the DLL and just returns a CDialog* to your application.
Be aware that this is only allowed and will work without problems when you are using the DLL shared version of the MFC.
Related
I came across a tutorial showing how to embed a child dialog within a parent dialog using MFC. I am using Visual Studio 2015. My setup is as follows. Using the Visual Studio MFC Application Wizard to create a new MFC Visual C++ Project called MFCApplication3, I select a Dialog based application where MFC is used in a Shared DLL. Using boilerplate code, I have a simple Thick Frame Dialog, no maximize or minimize box.
In my resource view, I go to my Dialog editor to edit the main dialog. I add a picture control with a blank area in the center and name it IDC_STATIC. This will simply be used as a placeholder for my child dialog that I wish to embed. It looks like:
Still in the resource view, I create a new Dialog. I call it IDD_CHILD. I add some components. It looks like this:
Now back in the Solution Explorer, I add a class using the Add Class wizard, selecting to add an MFC Class. The class name is CChildDialog, with a base class of CDialog, and I use the already generated IDD_CHILD as the Dialog ID. It generates the .cpp and associated .h file. In the constructor of CChildDialog, I add a call to the Create function so the constructor becomes:
CChildDialog::CChildDialog(CWnd* pParent /*=NULL*/)
: CDialog(IDD_CHILD, pParent)
{
Create(IDD_CHILD, pParent);
}
Now I modify the dialog code generated automatically when I created the project. In CMFCApplication3Dlg.h, I add a private member of type CChildDialog* called m_childDlg, and #include the associated header file. In CMFCApplication3Dlg.cpp, I add this to the OnInitDialog function prior to the return statement:
CRect rc;
GetDlgItem(IDC_STATIC)->GetWindowRect(rc);
ScreenToClient(&rc);
m_childDlg = new CChildDialog(this);
m_childDlg->MoveWindow(rc);
Now I build the solution, run it, but it looks like it does in the first picture. A blank placeholder spot for a child dialog, but no child dialog. What could I be doing wrong?
It turns out (while composing this question) that the answer to my problem was two properties I need to set while in the resource view. When I have the child dialog open (IDD_CHILD), within the properties pane, I need to set the following properties:
Style: Child
Visible: TRUE
(I am not sure why Visible defaults to FALSE in this case). Making those two changes, voila! I get my embedded dialog:
I am trying to create a new frame window with toolbars inside a dll.
I was able to create the frame and the toolbars but however the messages do not work properly in the CToolbar. Particularly the ON_UPDATE_COMMAND_UI messages are never called in the DLL.
After some research I came to know that this is because
PreTranslateMessage(MSG* pMsg)
and
OnIdle(LONG lCount)
need to be called.
But my calling application is Delphi based and this cannot be done.
After research I came to know that this is best possible from an Extension dll.
Since MFC extension dlls can only be called from an MFC application. I thought of the following solution.
Delphi calls an regular MFC dll
The MFC dll calls the Extension dll.
But I have run into problems because of asserts in in MFC AfxGetResourceHandle() and AfxGetInstanceHandle().
But I am also aware that AFX_MANAGE_STATE(AfxGetStaticModuleState()); cannot be called from an extension dll.
Does anybody have a solution for this problem?
The ON_UPDATE_COMMAND_UI messages are created by the MFC message loop. You don't have one. You will have to build your own ON_UPDATE_COMMAND_UI translator or something equivalent. It all starts with this in your frame window message map:
ON_WM_INITMENUPOPUP()
Your OnInitMenuPopup handler will be called when the user selects a menu, before the menu is displayed.
We have a VB6 application that we have provided extended functionality through an MFC DLL. However, there's a specific problem with CDialog-based classes in the DLL. We pass in Me.hWnd from the VB6 app's main form to give to the CDialog constructor so that DoModal() knows what its parent is. Although the CDialog-based classes are staying on top of the VB6 app on DoModal(), they do not block the VB6 app the way that's expected by a modal dialog. That is, while the DLL dialog remains in front of the EXE's window, I can still click the button that called the DLL, showing the dialog again (and again).
There's not much to show from the VB6 code. As I mentioned it just passes in Me.hWnd. The MFC code is simple enough:
HWND exeHwnd = pSessionContext->GetHWnd(); // our state container for the DLL
CWnd* exeWnd = CWnd::FromHandle(exeHwnd);
MyCDialog dlg(exeWnd);
INT_PTR result = dlg.DoModal();
// waits, stays in front, but does not "block" the window
switch (result) // ...
I traced the values along the way and confirmed window handles with Spy++. Everything seems to be fine. Any ideas what I'm missing or doing wrong?
ADDITIONAL INFO
That hwnd value is used elsewhere for MessageBox and works as expected.
A simplistic solution might be to disable the parent VB6 app in the VB6 code just before calling the DLL, and when the DLL code returns re-enable the VB6 app. Something like this (air code)
Me.Enabled = False
MagicDLL.ShowTheDialog(Me.hWnd)
Me.Enabled = True
I have an MFC application using satellites DLLs in order to support the multilingualism. I am using Visual Studio 2010.
I am able to change the language of the core part of the application without any problems. Things go wrong when I try to load a modeless dialog containing a "special" MFC control (CMFCColorButton, CVSListBox, etc).
The problem occurs at the following statement :
m_dlg->Create(SOME_IID, this); // returns false
How should I proceed to load a "special" MFC control from a satellite DLL?
You must register their classes before you reach OnCreate(). For custom controls, this is typically done in the constructor:
CMyClass::CMyClass()
{
// Pseudo code
m_mfcColorButton.RegisterWindowClass(AfxGetResourceHandle());
}
For MFC controls, I bet there is an initialization function that needs to be called.
I had the same problem: my CDialog - derived class failed in DoModal if I use localized resource dll. It contains CMFCColorButton on resource template.
My solution was to call in a resource dll AfxRegisterMFCCtrlClasses();
class CMyApp: public CWinApp
{
BOOL InitInstance()
{
AfxRegisterMFCCtrlClasses();
return CWinApp::InitInstance();
}
};
I'm having problems displaying a modal Qt dialog while starting up a Qt application from an MFC application. Specifically, a QProgressDialog instance won't display within the MFC application when I set its parent to a QWinWidget instance. Here's my problem in more detail...
My MFC application needs to transfer a lot of data over to the Qt application, which is a DLL. The Qt application includes a ProgressDlg class in its API that behind the scenes is implemented using a QProgressDialog. This dialog must be created and updated before the Qt application's event loop is initialised so that the MFC application can update its progress (The QApplication::exec() help says this is possible with modal widgets).
Without setting the underlying QProgressDialog's parent, the progress bar gets updated as I would expect and the dialog remains responsive during the transfer, but I can continue to interract with the MFC application.
So I tried installing the Qt/MFC Migration Framework and setting the QProgressDialog's parent to be a QWinWidget:
void ProgressDlg::SetParent(HWND hParentWnd)
{
QWinWidget* w = new QWinWidget(hParentWnd);
m_impl->setParent(w);
}
(where m_impl derives from QProgressDialog.)
And then adding the calling code on the MFC side to create the dialog:
HWND hWnd = FindWindow(NULL, "ABC");
if(hWnd)
{
ProgressDlg dlg;
dlg.SetParent(hWnd);
//...
dlg.SetValue(0);
//...
}
However in setting the parent, the QProgressDialog no longer appears. (I retrieved the handle using ::FindWindow, passing in the Window Name, as to complicate the scenario further, my MFC application is actually a plugin DLL to a 3rd party executable.)
All help appreciated. Thanks.
Gotcha! The problem was caused by the call to SetParent(). I needed to instead create the QWinWidget before the QProgressDialog and pass the QWinWidget instance in to the QProgressDialog's constructor as its parent.
As the help says, QWidget::setParent resets the window flags, so the dialog was no longer being recognised as a dialog.