moving a mfc app into a dll
-
I am trying to figure out how I can best move an existing mfc dialog app into a dll and then be able to launch it from a console based application when needed. I understand the basics of dll importing / exporting and how to create and use a dll I just want to know how do I get the app now insider a dll to initialize and show itself? basically the mfc is an observer type object and once created and made visible I can grab it's interface and start providing it data to output in the window.
Yours Truly, The One and Only!
-
I am trying to figure out how I can best move an existing mfc dialog app into a dll and then be able to launch it from a console based application when needed. I understand the basics of dll importing / exporting and how to create and use a dll I just want to know how do I get the app now insider a dll to initialize and show itself? basically the mfc is an observer type object and once created and made visible I can grab it's interface and start providing it data to output in the window.
Yours Truly, The One and Only!
Just write a console app to launch your existing app. There's no need to put it into a DLL.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Just write a console app to launch your existing app. There's no need to put it into a DLL.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Not going to work in my case. This is going to be a part of a 3rd party tool I am working on, I rather that other developers link to the dll and be able to use it without any gui or mfc knowledge.
Yours Truly, The One and Only!
-
I am trying to figure out how I can best move an existing mfc dialog app into a dll and then be able to launch it from a console based application when needed. I understand the basics of dll importing / exporting and how to create and use a dll I just want to know how do I get the app now insider a dll to initialize and show itself? basically the mfc is an observer type object and once created and made visible I can grab it's interface and start providing it data to output in the window.
Yours Truly, The One and Only!
This may help - Kinds of DLLs[^] Particularly the sections related to regular DLLs linked with MFC. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
This may help - Kinds of DLLs[^] Particularly the sections related to regular DLLs linked with MFC. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Thanks Mark, :-D I already know about DLLs... I am just trying to contain all the MFC GUI logic inside a dll and then have a simple way to evoke the MFC Dialog based app I created with the Wizard. I would also like to be able to call this GUI from a console based app provided all the relevant mfc / windows definitions are included. I know it's possible after all you can throw up a message box from a console app :-D
Yours Truly, The One and Only!
-
Thanks Mark, :-D I already know about DLLs... I am just trying to contain all the MFC GUI logic inside a dll and then have a simple way to evoke the MFC Dialog based app I created with the Wizard. I would also like to be able to call this GUI from a console based app provided all the relevant mfc / windows definitions are included. I know it's possible after all you can throw up a message box from a console app :-D
Yours Truly, The One and Only!
Right - that's why I said look into those specific links. MFC apps may require certain objects to exist and certain initialization to be done, depending on how you're using it. That link is a starting point to those details. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Right - that's why I said look into those specific links. MFC apps may require certain objects to exist and certain initialization to be done, depending on how you're using it. That link is a starting point to those details. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
LOL are we going to play message Tag =P I am familiar with that section of the DLL in MSDN, which basically is talking about the types of DLL, but I will take another look at it. FYI: I was able to convert the mfc app into a dll package and have it build cleanly and spit out the dll and lib files for linking. I have also been able to link the mfc dll from my console based app and have it load the dll into the process space. What do I need to do to create an instance of my MFC app which is deriver from CWinApp and have it initialized to be able to show my Dialog based window? All the logic I have that I need is inside the dialog based window class..so do I even need to worry about CWinApp, is there a way just to create a modeless window that has it's own message loop?
Yours Truly, The One and Only!
-
LOL are we going to play message Tag =P I am familiar with that section of the DLL in MSDN, which basically is talking about the types of DLL, but I will take another look at it. FYI: I was able to convert the mfc app into a dll package and have it build cleanly and spit out the dll and lib files for linking. I have also been able to link the mfc dll from my console based app and have it load the dll into the process space. What do I need to do to create an instance of my MFC app which is deriver from CWinApp and have it initialized to be able to show my Dialog based window? All the logic I have that I need is inside the dialog based window class..so do I even need to worry about CWinApp, is there a way just to create a modeless window that has it's own message loop?
Yours Truly, The One and Only!
I'll rip the relevent portions for you: "A regular DLL, statically linked to MFC, has the following requirements: This type of DLL must instantiate a class derived from CWinApp. This type of DLL uses the DllMain provided by MFC. Place all DLL-specific initialization code in the InitInstance member function and termination code in ExitInstance as in a normal MFC application. Even though the term USRDLL is obsolete, you must still define "_USRDLL" on the compiler command line. This definition determines which declarations is pulled in from the MFC header files" "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." "A regular DLL, dynamically linked to MFC has the following requirements: These DLLs are compiled with _AFXDLL defined, just like an executable that is dynamically linked to the MFC DLL. But _USRDLL is also defined, just like a regular DLL that is statically linked to MFC. This type of DLL must instantiate a CWinApp-derived class. This type of DLL uses the DllMain provided by MFC. Place all DLL-specific initialization code in the InitInstance member function and termination code in ExitInstance as in a normal MFC application. Because this kind of DLL uses the dynamic-link library version of MFC, you must explicitly set the current module state to the one for the DLL. To do this, use the AFX_MANAGE_STATE macro at the beginning of every function exported from the DLL. 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 your DLL brings up modeless dialogs or has a main frame window of its own, your application's main message pump must call a DLL-exported routine that calls CWinAp
-
I'll rip the relevent portions for you: "A regular DLL, statically linked to MFC, has the following requirements: This type of DLL must instantiate a class derived from CWinApp. This type of DLL uses the DllMain provided by MFC. Place all DLL-specific initialization code in the InitInstance member function and termination code in ExitInstance as in a normal MFC application. Even though the term USRDLL is obsolete, you must still define "_USRDLL" on the compiler command line. This definition determines which declarations is pulled in from the MFC header files" "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." "A regular DLL, dynamically linked to MFC has the following requirements: These DLLs are compiled with _AFXDLL defined, just like an executable that is dynamically linked to the MFC DLL. But _USRDLL is also defined, just like a regular DLL that is statically linked to MFC. This type of DLL must instantiate a CWinApp-derived class. This type of DLL uses the DllMain provided by MFC. Place all DLL-specific initialization code in the InitInstance member function and termination code in ExitInstance as in a normal MFC application. Because this kind of DLL uses the dynamic-link library version of MFC, you must explicitly set the current module state to the one for the DLL. To do this, use the AFX_MANAGE_STATE macro at the beginning of every function exported from the DLL. 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 your DLL brings up modeless dialogs or has a main frame window of its own, your application's main message pump must call a DLL-exported routine that calls CWinAp
yes that is better ;P ... LOL Hopefully I can display the dialog window without too much work!
Yours Truly, The One and Only!
-
I am trying to figure out how I can best move an existing mfc dialog app into a dll and then be able to launch it from a console based application when needed. I understand the basics of dll importing / exporting and how to create and use a dll I just want to know how do I get the app now insider a dll to initialize and show itself? basically the mfc is an observer type object and once created and made visible I can grab it's interface and start providing it data to output in the window.
Yours Truly, The One and Only!
This was a lot simpler that I first thought :laugh: When I rediscovered AfxSetResourceHandle() everything came together!
Yours Truly, The One and Only!
