In the midst of all this publicity writing ATL-based applications, you will
find little in the way of documentation on porting your legacy Win32 applications to
ATL. Hopefully, these steps will ease that migration path.
Include AtlBase.h file in StdAfx.h after AfxWin.h. This is to take advantage to
declare a variable for CComModule. Because AtlWin.h file needs, _Module as variable
We have to keep extern because we are originally declaring variable in
Application main file.
extern CComModule _Module;
Then include the remaining files which helps for an ATL Application. In the insert Object of ATL uses ATLHost.h which needs to compile atlcom.h as before.
In the StdAfx.cpp, Include AtlImpl.cpp file.
In the main Application file, add the following
//originally declaring the CComModule variable
Then, Add the following two lines, which are required to activate ATL
Object Wizard, when you choose Insert ATLObject from Insert Menu.
Initialize the CComModule variable with ObjectMap and with the current
instance in the WinMain function
Add the <ProjectName>.idl file into the project and add the library related code:
If you want to insert a dialog and want to show. Follow the above steps and
declare the variable of ur dialog class and call DoModal with that variable
(don't forget to include dlg header file).
This code has been tested with and works fine with the Windows CE environment.
References and Acknowledgments
ATL Internals - Rector, Sells (My thanks to the Authors!)
Instead of only managing projects organizations do need to manage value!
"Doing the right things" and "doing things right" are the essential ingredients for successful software and systems delivery. Unfortunately, with distributed delivery spanning multiple disciplines, geographies and time zones, many organizations
struggle with teams working in silos, broken lines of communication, lack of collaboration, inadequate traceability, and poor project visibility. This often results in organizations "doing the …
With JRebel, developers get to see their code changes immediately, fine-tune their code with incremental changes, debug, explore and deploy their code with ease (both locally and remotely), and ultimately spend more time coding instead of waiting for the dreaded application redeploy to finish.
Every time a developer tests a code change it takes minutes to build and deploy the application. JRebel keeps the app server running at all times, so testing is instantaneous and interactive.