Got a third party ActiveX dll which has control dialog for a fan. Would like to access the ACtiveX dll from a MFC dll with APIs, so that be able open the control dialog and access some other functions in the ActiveX. IS this practically easy?., and what resources should be called where?. any examples?. Need to record temperature continuously while no around around.
After reading so much at the microsoft site, came up with a MFC dll that its dialog uses an ActiveX control. Also, wrote a MFC and a console applications that by calling dll's opendialog(), I see the dialog launches. I hope I am not causing any memory leak. or causing any resource (de)allocation errors without knowing. so far , things seem to be working.
BOOL CDllApp::InitInstance()
{
CoInitialize(0);
AfxEnableControlContainer();
return CWinApp::InitInstance();
}
int CDllApp::ExitInstance()
{
CoUninitialize();
return CWinApp::ExitInstance();
}
In another class, in the same mfc dll, i do this.:
void CMyClass::opendialog()
{
AFX_MANAGE_STATE(AfxGetStaticModuleState( ));
CMyDialog dlg;
dlg.DoModal();
}
Related
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.
My MFC application is a MDI application. and I have a MFC Extension dll, MFC Extension dll will launch the child dialog on top of the MFC MDI application. like as below
CMyDialog pDisplayGlobal = new CMyDialog(IDD_DISPLAY, NULL);
pDisplayGlobal->Create(IDD_DISPLAY, AfxGetApp()->m_pMainWnd);
pDisplayGlobal->ShowWindow(SW_NORMAL);
Note : Kindly let me know if I am doing anything wrong in above code.
Problem:
I have launched my MFC mdi application and child modeless dialog as well. Modeless dialog always on top of parent window only (as per the above code)
Step1) I have opened other four different applications (Which means my MFC application is behind these four applications)
Step2) I clicked on my MFC application from the Taskbar it’s not showing the main application window. which means it didnt come in front its still in step1 stage only
Step3) To see My MFC application I have to minimize all the four applications
That’s the problem, kindly somebody give me some code snippet as a solution.
Thanks in advance.
To run a dialog from another program you can do the following
in DLL:
CDialog *g_dlg;
void dll_foo()
{
g_dlg = new CDialog;
g_dlg->Create(IDD_DIALOG1);
g_dlg->ShowWindow(SW_SHOWNORMAL);
}
in main app:
BOOL CMyWinApp::InitInstance()
{
//...
frame->ShowWindow(SW_SHOWNORMAL);
frame->UpdateWindow();
dll_foo();
return TRUE;
}
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 want to open a MFC modeless dialog from a MFC dll injected into another process, the dll's job is to hook the winsock send & recv, and the dialog will be the interface to communicate with the dll. The dll should be able to run the hook while the dialog is running.
BOOL CDriverApp::InitInstance()
{
CWinApp::InitInstance();
if (!AfxSocketInit())
{
AfxMessageBox(IDP_SOCKETS_INIT_FAILED);
return FALSE;
}
AfxMessageBox("I'm In!");
DetourTransactionBegin();
DetourUpdateThread( GetCurrentThread() );
DetourAttach( &(PVOID &)RealSend, MySend );
DetourAttach( &(PVOID &)RealRecv, MyRecv );
if ((DetourTransactionCommit()) == NO_ERROR)
{
AfxMessageBox("Winsock hooked");
}
dlg = new ControlDlg();
m_pMainWnd = dlg;
if(dlg->Create(IDD_CONTROL_DLG))
{
dlg->ShowWindow(SW_SHOW);
}
//ExitThread(0);
return TRUE; <---
}
dlg is the dialog which is a member of CDriverApp
From what i have observed, the dialog is destroyed because the thread has exited and the memory that hold the dialog is removed.
The thread '_DllMainCRTStartup' (0x418) has exited with code 1657602048 (0x62cd0000).
I have read MFC modeless dialog close immediately thread, but my InitInstance() already returned true from the first place, so it's a different problem (i think)
So, my question is how to prevent the dialog from destroyed? Or perhaps prevent the thread from exit? or is it doable with a modal dialog?
This may be your problem:
Regular DLLs must have a CWinApp-derived class and a single object of
that application class, as does an MFC application. However, the
CWinApp object of the DLL does not have a main message pump, as does
the CWinApp object of an application.
Note that the CWinApp::Run
mechanism does not apply to a DLL, because the application owns the
main message pump. If the DLL opens modeless dialogs or has a main
frame window of its own, the application's main message pump must call
a routine exported by the DLL that in turn calls the
CWinApp::PreTranslateMessage member function of the DLL's application
object.
http://msdn.microsoft.com/en-US/library/f22wcbea(v=vs.80)
EDIT:
THis shows how to do what you are doing with a cWnd instead of a CDialog. Personally I think thats a better way to go.
http://codinganswer.com/c/cwnd-in-a-new-thread-in-a-dll.html
Here is an example of attaching a message hook to a modeless.
http://support.microsoft.com/kb/q187988/