I have made an MFC application (VS2010) - exe.I then changed it to be dll (in project properties).
Some class CmyClass is inheriting CWinApp in my MFC dll.
From the other DLL (standard win32 DLL) I want to create the class and call it as it made by running the MFC as application (EXE).
I have tried to declare the CmyClass with DLLEXPORT, in my win32 DLL I Load the MFC dll dynamically and performing AfxWinInit with the hinstance of the MFC dll.
I have tried than to:
Create (CmyClass * a= new CmyClass()), wanted to call InitApplication(), InitInstance() and Run()
Call AfxGetApp() -> retrieving NULL pointer.
All without success. What Am I doing wrong?
10x,
Guy
EDIT:
I need the other way around though... I have created MFC App since it's wizard is wider and richer then the MFC Dll one. I want to consume this Dll the same manner I will consume the App (Exe). I found that from the consuming Dll it is sufficient just to LoadLibrary(MFCDll) to start the MFC Initialization (AfxWinInit is called and CMyClass->InitInstance is being called as well, but fails afterwards with exceptions.
Related
In vs mfc project,an ActiveX control can be added in "tools"->Add Class from ActiveX Control Wizard.That will create a class which inherited from CWnd and I can create an instance of ActiveX by calling CreateControl.But I just want to call the inner interface function in ActiveX,not its UI.So how to use it in a non-MFC app or someother's project without UI,such as dll or com,etc.
ActiveX is just COM so you may create instance from clsid and call methods of it.
I am working on the OPC(OLE process Control)Client program,with the asynchronous CALLBACK methods to get data from PLC using the KepServer.But I encountered the issue:
CComObject<COPCDataCallback>* pCOPCDataCallback; // Pointer to Callback Object
// Create Instance of Callback Object using an ATL template
CComObject<COPCDataCallback>::CreateInstance(&pCOPCDataCallback);
and then it stopped at here:
_pAtlModule->Lock();
this is in the atlcom.h
any ideas of how to solve this issue?
When you are using ATL classes like CComObject, it is assumed that you have an ATL project, with "ATL module" class defined in it, such as CAtlExeModuleT based for EXE application.
With no module class/instance defined, there is no initialization of global internal _pAtlModule variable and hence the problem. You need to add the module class.
One of the ways to add ATL support is using IDE, typically if your existing project is MFC-based:
Adding ATL support to existing mfc application
How to get ATL support into an existing Windows application
Another way is to add CAppModule instance, if your project is using WTL:
CAppModule vs CAtlExeModuleT , getting the application message loop
Then third way is to create a new clean ATL project of matching type (EXE or DLL) using Visual Studio wizard, and to check the code around CAtlDllModuleT or CAtlExeModuleT classes, then to duplicate that in your existing project.
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.
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();
}
};
First of all: Is this even possible?
I have a third party dll that interfaces some hardware. It's written in MFC. I received (from the dll vendors) a sample Visual Studio 2010 solution which has only one project: An MFC application (.exe) which calls the third party dll in question. It works fine.
When I try to use the third party dll from my dll (which is plain C++, no MFC, no .NET), I can call its functions fine, but there's a catch: the sample MFC app seems to "override" MessageProc in order to capture certain messages that the third party dll generates. And though the dll has a function called "RegisterFuncCallback" and I use it, my callback never gets called.
So here's the problem: How can I capture those messages without creating an MFC app? (Is it even possible?)
Alright, I made it. Here's how:
Create a class which inherits from CWnd
Declare a message map associating the desired messages and their handlers
When creating the Window, use the CreateEx function (I did it in my class's constructor), and pass it the HWND_MESSAGE flag in the last but one parameter. This will create the window as a "Message Window", that is, invisible.
Once I'm done initializing the window and the MFC dll, I call RunModalLoop on my hidden window, in a separate thread, since it's blocking. This fires up the message pump, and starts receiving the MFC dll's messages.
Edit: I could finally do it using just Win32 API. Here's my story, code included:
Programate Algo Blog. Don't worry, it's in English.
If the DLL works with Win32 messages you won't get around them. But you do not neccessarily need MFC for that, a simple WinAPI solution would suffice. MFC just wraps the Win32 API. If those messages aren't Win32 messages, you do not need a Win32 application.