Win32++: A Simple Alternative to MFC(界面 源码很强大)
来源:互联网 发布:蓝牙耳机知乎 编辑:程序博客网 时间:2024/05/22 09:43
Win32++ is a simple and easy to understand library for creating windows applications. It runs on the commonly available free compilers, making it a free alternative to MFC. Win32++ has been designed to make life a little easier for those learning to use C++ to program using the Windows API directly. Win32++ doesn't attempt to hide the Windows API. On the contrary, it exposes the Windows API, allowing it to be more easily learnt and understood. Win32++ is also a good choice for those professional programmers looking for a simple, robust and efficient framework. The code has been designed to run on a wide range of C++ compilers, including those from Microsoft, Borland and the free MinGW compiler from GNU. Win32++ supports all Windows operating systems, from Windows 95 through to Windows 7. It can be used to create both 32 bit and 64 bit applications. Win32++ also directly supports the Windows CE operating system. Windows CE is the operating system which runs on the various Pocket PCs, Smartphones, as well as industrial devices and embedded systems. The Windows CE API is a subset of the Windows API. It also includes some new common controls tailored for the smaller computers and devices it runs on. Win32++ brings an object oriented approach to programming directly with the Windows API. Each window created is a C++ class object capable of having its own window procedure for routing messages. When I first approached the task of teaching myself to program Windows using C++, I took a brief look at some of the Win32 tutorials on the Web and then jumped straight into using MFC. I hoped that using MFC might make the task of learning Windows programming easier. With the benefit of hindsight, I now realize that this approach was a mistake. I should have taken the time to study the Windows API more thoroughly before moving on to MFC. It would have been far easier (and faster) to approach these two topics one at a time, instead of trying to learn both of them at once. In a sense, I should have learned to walk before trying to run. The two main challenges I faced when writing Win32 applications were: With this in mind, I decided to revisit my Windows API programming and develop a generic Framework for my applications that could be used as an alternative to MFC. My goal was to produce a Framework that was robust, object-oriented and that produced professional-looking results. The following diagram illustrates the classes used in Win32++: The classes which define the Framework itself are contained within the The file download from Sourceforge includes the following: The sample applications include: The code which forms the basis of the Framework is located in the Win32++ directory. You shouldn't need to modify these files, but rather inherit from Win32++ and add any additional code in your derived classes. To use the Framework to create an SDI frame window, for example, you would typically derive your own class from A separate view window is placed over the client area of the frame window. Typically, this view window is created by inheriting a class from One of the important advantages of programming directly with the Windows API is that the code produced is portable, which is to say that it can be compiled on different compilers. The code in this Framework has been checked for compatibility with Visual C++ 6.0, Visual Studio .NET 2003, Visual C++ 2008 Express Edition, and also Dev-C++ version 4.9.9.2. Dev-C++ is a free C++ compiler and Integrated Development Environment available for download from here. The Framework is also compatible with Visual C++ Toolkit 2003 (a free compiler from Microsoft) and Borland's free Turbo C++ 2006. A tutorial which provides step by step instructions for using the Framework is included with the framework. The key to bringing an object-oriented approach to programming directly with the Windows API is to have a C++ class that can create a window and which includes its own window procedure as a member function. Once we have this class, we can inherit from it and override the window procedure member function to handle messages the way we want for each derived window type. Creating a class like this is not trivial and I suspect that's one of the reasons why MFC was created in the first place. The problem stems from the way a "window class" is registered before the window can be created. The term "class" here refers to the Windows API "window class," which is not the same thing as a C++ class. The following code snippet shows how a window class might be registered using the API: Note that we need to supply the function name of our window procedure. The window procedure is where we control what is to be done when a window message is received. This function must conform precisely to the predefined standards required by the Windows API. A typical declaration of the callback function looks like this: We might be tempted to set the We can make the A Step 1: Set up the Thread Local Storage to store our Step 2: Store our Step 3: Extract the pointer from Thread Local Storage and add it to the STL map during the initial creation of the window: Step 4: For each subsequent window message, we extract the pointer from the STL map and use it to redirect the message handling to the appropriate Now that we've had a look at thread local storage and the window procedure, it is time to see how these fit together as we create the window. This is the code that creates the window: The next code segment handles the window procedure which first receives the messages. We extract the pointer to the Finally, the next code segment shows the function called by The method described here uses a global map to associate a windows handle (HWND) with a CWnd object. This map uses Thread Local Storage (TLS) to ensure that the creation of the windows thread safe. If TLS wasn't used, attempts to create multiple windows simultaneously in different threads could fail. Using a map to associate a windows handle (HWND) with a CWnd object also allows every message for the window to be processed. There is no need, for example, to discard window messages prior to WM_NCCREATE when using this method. The latest version of Win32++ can be downloaded from the SourceForge here. Win32++ uses CDocker to support docking and splitter windows. When docking, the undocked docker is dragged over another docker. Various visual clues such has the dock targeting (small arrow-like images), and the dock hinting (where a portion of the destination window turns blue) provide a hint as to where the docker will be docked. To facilitate undocking, the caption of the docked window is dragged and dropped. Virtually any child window can be used as the view window for a docker. The CContainer class provides a specialised view for dockers which has tabs, and also has an optional toolbar. The CTabbedMDI class adds support for tabbed MDIs. These behave much like a traditional Multiple Document Interface, but uses a tab control to manage the various child MDI windows. Refer here for a detailed list of revision changes. This article, along with any associated source code and files, is licensed under The MIT LicenseIntroduction
Background
Framework Overview
Win32xx
namespace. These classes are as follows:CBitmapInfoPt
: A class used to simplify the creation and use if the BITMAPINFO structure for use with GDI graphics.CCmdbar
: A class used on Windows CE to provide a CommandBar
. It is used by CFrame
on Windows CE.CContainer
: A specialised view window for dockers. It has tabs and an optional toolbar.CCriticalSection
: This class provides for thread synchronization for multi-threaded applications.CDC
: A class which represents a Device Context. It simplifies working the Windows GDI.CDialog
: The class responsible for creating modal and modeless dialogs. It is used by CFrame
, and can also be used to create dialog applications.CDocker
: A class which provides support for docking and splitter windows.CFrame
: This class produces a frame window which has a rebar, menubar, toolbar, and a status bar. The client area of the frame window should be occupied by a separate CWnd
object.CListView
: A class used to create a list-view control.CMDIApp
: This class is inherited from CWinApp
. You should inherit from this class to start an MDI frame application.CMDIChild
: This is the class to be used for MDI children. Each MDI child should be inherited from this class.CMDIClient
: This is a class used internally by Win32++ as the view window for the MDI frame.CMDIFrame
: This class is responsible for creating the MDI frame window. It is inherited from CFrame
.CMenubar
: This class is responsible for creating the menubar. A menubar is a menu housed inside a rebar control.CPoint
: This class can be used in place of a POINT structure.CPropertyPage
: This class adds support for property pages to Win32++. A property page has one or more property sheets.CPropertySheet
: This class represents a property page. It is used by CPropertySheet
.CRebar
: This class is responsible for creating the rebar. It is used by CFrame
.CRect
: This class can be used in place of a RECT structure.CSize
: This class can be used in place of a SIZE structure.CSocket
: This class adds network support to Win32++.CStatusBar
: The class responsible for creating the status bar. It is used by CFrame
.CTab
: A class used to create a tab control.CToolBar
: The class responsible for creating the toolbar. It is used by CFrame
.CTreeView
: A class used to create a tree-view control.CWceFrame
: A class which provides a simple frame for Pocket PCs. It utilises a Commandbar
to display the menu and toolbar buttons.CWinApp
: The class responsible for initializing the Framework, and also provides our message loop. You should inherit from this class to start the Framework.CWinException
: A class which handles exceptions.CWnd
: The class responsible for the window objects. It is the base class for the more specialized window objects such as CDialog
, CFrame
,CToolbar
etc.About the File Downloads
Browser
- An Internet browser application based on ActiveX controls.Dialog
- An example of a simple dialog application.DialogDemo
- An interative dialog application demonstrating slider controls and progress bars.DialogTab
- A dialog application with a tab control.DirectX
- A simple DirectX application.Dock
- An example of a simple docking application.DockContainer
- An example of a docking application which incorporates containers.DockTabbedMDI
- An example of a docking application with containers and a tabbed MDI.Explorer
- A Windows Explorer-like application.FastGDI
- An application which demonstrates direct manipulation of a bitmap's colour.FormDemo
- An example of a modeless dialog within a frame.MDIFrame
- A simple MDI frame applicationsMDIFrameDemo
- Demonstrates some additional features of MDI frames.Networking
- Demonstrates the use of networking.Notepad
- A simple text editor with printing.Performance
- Measures Win32++'s message handling speed.Picture
- A simple picture rendering application.PropertySheets
- A demonstration of property sheets.Scribble
- A simple drawing application.Simple
- Creates a simple window.Splitter
- A demo of the CSplitter
class.StaticLibrary
- Builds the Win32++ framework into a static library.TabDemo
- Demonstrates the use of a CTab control in a frame.Themes
- Demonstrates how to customise the colours for rebar and toolbar controls.Threads
- Demonstrates multi-threaded Windows.WinCE samples
- A small collection of samples for Windows CEUsing the Framework
CFrame
and place any modifications to the standard frame there. You can override the WndProc
member function to include any additional messages you would like to handle.CWnd
. TheCFrame::SetView
function is used to assign the view window to the frame. For MDI frames however, the CMDIFrame
already uses CMDIClient
as the view window, and you would use CMDIFrame::AddMDIChild
to create a new instance of an MDI child window.Object-oriented Approach
WNDCLASSEX wc = {0}; wc.cbSize = sizeof(WNDCLASSEX);wc.lpfnWndProc = WindowProc; //Window procedure function wc.hInstance = hInstance;wc.lpszClassName = "TEST";wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1); //Register the window class::RegisterClassEx(&wc);
LRESULT CALLBACK WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
WindowProc
function as a member of the class. Unfortunately, each class member function has an implicit this
pointer as one of its arguments and therefore cannot be used as the callback function for a window. If we did this, our WindowProc
function would no longer conform to the predefined standards and the program would fail to compile.WindowProc
function a static
member function of the class. There is no implicit this
in a static
function and this will compile correctly. Unfortunately, a static
member function doesn't have access to the class object (i.e. it doesn't have a this
pointer) and it cannot access other members of the class. It is this that prevents the static
member function from being used in an object-oriented way. The following code demonstrates the limitations of a static
member function approach:class TestStatic{public: int member; void NormalFunction() { //We can access member variables in a normal //member function member = 5; //The following line is equivalent to the one above this->member = 5; } void static StaticFunction() { //We cannot access member variables //in a static member function //The following line will give a compile error member = 5; //This will give an error too this->member = 5; }};
static
member function for the window procedure would be useful if we could just get our hands on a pointer to the window class object (our this
pointer). There are a number of techniques that we can use to get access to our pointer as the window is being created. The one I have chosen takes advantage of Thread Local Storage to store our pointer, which is later inserted into an STL map. This is how it's done:this
pointer. This is done in the CWinApp
class:CWinApp::CWinApp(HINSTANCE hInstance) : m_hInstance(hInstance){ if (GetApp() == 0) { st_dwTlsIndex = ::TlsAlloc(); //snip }}
this
pointer in the Thread Local Storage when we use CreateEx
to create the window:// Ensure this thread has the TLS index setTLSData* pTLSData = GetApp()->SetTlsIndex(); // Store the CWnd pointer in thread local storagepTLSData->pCWnd = this;
// Retrieve the pointer to the TLS DataTLSData* pTLSData = (TLSData*)TlsGetValue(GetApp()->GetTlsIndex()); // Retrieve pointer to CWnd object from Thread Local Storage TLSw = pTLSData->pCWnd; // Store the CWnd pointer in the HWND mapGetApp()->AddToMap(hWnd, w); return w->WndProc(hWnd, uMsg, wParam, lParam);
WndProc
function:CWnd* w = GetApp()->GetCWndFromMap(hWnd);return w->WndProc(hWnd, uMsg, wParam, lParam);
Window Creation in Detail
HWND CWnd::CreateEx(DWORD dwExStyle, LPCTSTR lpszClassName, LPCTSTR lpszWindowName, DWORD dwStyle, int x, int y, int nWidth, int nHeight, HWND hParent, HMENU hMenu, LPVOID lpParam /*= NULL*/){ try { // Test if Win32++ has been started if (0 == GetApp()) throw CWinException(_T("Win32++ has not been initialised properly./n Start the Win32++ by inheriting from CWinApp.")); // Only one window per CWnd instance allowed if (::IsWindow(m_hWnd)) throw CWinException(_T("CWnd::CreateEx ... Window already exists")); // Ensure a window class is registered TCHAR ClassName[MAX_STRING_SIZE] = _T(""); if (0 == lstrlen(lpszClassName) ) lstrcpyn (ClassName, _T("Win32++ Window"), MAX_STRING_SIZE); else // Create our own local copy of szClassName. lstrcpyn(ClassName, lpszClassName, MAX_STRING_SIZE); WNDCLASS wc = {0}; wc.lpszClassName = ClassName; wc.hbrBackground = (HBRUSH)::GetStockObject(WHITE_BRUSH); wc.hCursor = ::LoadCursor(NULL, IDC_ARROW); if (!RegisterClass(wc)) // Register the window class (if not already registered) throw CWinException(_T("CWnd::CreateEx Failed to register window class")); // Ensure this thread has the TLS index set TLSData* pTLSData = GetApp()->SetTlsIndex(); // Store the CWnd pointer in thread local storage pTLSData->pCWnd = this; // Create window m_hWnd = ::CreateWindowEx (dwExStyle, ClassName, lpszWindowName, dwStyle, x, y, nWidth, nHeight, hParent, hMenu, GetApp()->GetInstanceHandle(), lpParam); // Now handle window creation failure if (!m_hWnd) throw CWinException(_T("CWnd::CreateEx ... Failed to Create Window")); m_hWndParent = hParent; // Automatically subclass predefined window class types ::GetClassInfo(GetApp()->GetInstanceHandle(), lpszClassName, &wc); if (wc.lpfnWndProc != st_pfnWndProc) { Subclass(); // Send a message to force the HWND to be added to the map ::SendMessage(m_hWnd, WM_NULL, 0, 0); OnCreate(); // We missed the WM_CREATE message, so call OnCreate now } // Clear the CWnd pointer from TLS pTLSData->pCWnd = NULL; // Window creation is complete. Now call OnInitialUpdate OnInitialUpdate(); } catch (const CWinException &e) { e.MessageBox(); } return m_hWnd; } // HWND CWnd::CreateEx()
CWnd
object from the map, and use it to redirect the handling of the window messages to the appropriate WndProc
function:LRESULT CALLBACK CWnd::StaticWindowProc (HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam){ try { CWnd* w = GetApp()->GetCWndFromMap(hWnd); if (0 != w) { // CWnd pointer found, so call the CWnd's WndProc return w->WndProc(hWnd, uMsg, wParam, lParam); } else { // The CWnd pointer wasn't found in the map, so add it now // Retrieve the pointer to the TLS Data TLSData* pTLSData = (TLSData*)TlsGetValue(GetApp()->GetTlsIndex()); if (NULL == pTLSData) throw CWinException(_T("CWnd::StaticCBTProc ... Unable to get TLS")); // Retrieve pointer to CWnd object from Thread Local Storage TLS w = pTLSData->pCWnd; if (NULL == w) throw CWinException(_T("CWnd::StaticWindowProc .. Failed to route message")); pTLSData->pCWnd = NULL; // Store the CWnd pointer in the HWND map GetApp()->AddToMap(hWnd, w); // Store the HWND in the CWnd object early w->m_hWnd = hWnd; return w->WndProc(hWnd, uMsg, wParam, lParam); } }//snip
StaticWindowProc
. Typically, when we derive a new class from CWnd
, we would override this function to control the way various window messages are handled:LRESULT CWnd::WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam){ // Override this function in your class derived from CWnd to handle // window messages. A typical function might look like this: // switch (uMsg) // { // case MESSAGE1: // Some Windows API message // OnMessage1(); // A user defined function // break; // Also do default processing // case MESSAGE2: // OnMessage2(); // return x; // Don't do default processing, but instead return // // a value recommended by the Windows API documentation // } // Always pass unhandled messages on to WndProcDefault return WndProcDefault(hWnd, uMsg, wParam, lParam);}
History
CDialog
CWinApp
CWnd
pointer. This allows the lpParam
parameter to be used for user data when creating a window.CRebar
, CMenubar
, CSplitter
CSocket
for network supportCDC
to simplify using Windows Graphics Device Interface (GDI)CPoint
, CRect
and CSize
CListView
and CTreeView
CTab
and CTabbedMDI
What's New
Reference Material
License
About the Author
Australia
Member
链接:http://www.codeproject.com/KB/winsdk/framework.aspx
- Win32++: A Simple Alternative to MFC(界面 源码很强大)
- Win32++: A Simple Alternative to MFC(界面 源码很强大)
- Win32++: A Simple Alternative to MFC(界面 源码很强大)
- Handling HTML Element Events in MFC applications - A simple alternative approach
- An alternative to VC++ and MFC
- SkipList A Probabilistic Alternative to Balanced Trees
- MFC+opencv+win32界面编程
- A Simple Way to Enable a Windows XP Look and Feel for VC++ 6.0 MFC Applications
- Creating a Simple Win32 Service in C++
- Creating a Simple Win32 Service in C++
- A Simple Win32 Window Wrapper Class
- Skip Lists: A Probabilistic Alternative to Balanced Trees
- MFC界面相关源码
- A very simple MFC class to Encode and Decode an url string
- A Simple Introduction To Shell
- A SIMPLE WAY TO USE SELECT (socket)
- a simple way ,to programing or writting!
- How to write a simple Makefile
- linux gdb配合core文件进行强强联手
- ——
- asp导出到excel
- 23岁我写了第一封情书
- Tracing Tips and Resources
- Win32++: A Simple Alternative to MFC(界面 源码很强大)
- JavaScript的StringBuffer工具
- JavaScript的StringBuffer工具
- Win32++: A Simple Alternative to MFC(界面 源码很强大)
- Win32++: A Simple Alternative to MFC(界面 源码很强大)
- 线性时间排序(二)C语言
- 浅谈STL中的输入流迭代器和输出流迭代器
- 乱
- XTU 2011 新生练习赛 Problem B N! Last non zero