Tabbars code interpretation-relationship between the tabbar Bar and other windows

The actions of various windows in the integrated development environment are implemented in advance. For example, the document editing window corresponds to a multi-document View window, which responds to user input and updates the window content, the main window schedules various View windows. The integrated development environment (IDE) of Visual Studio does not provide us with any interfaces to add a window to the IDE, and this window can share messages with other windows in the IDE, that is to say, under normal circumstances, the plug-in cannot interfere with the normal behavior of windows in the IDE environment. However, this does not mean that we can only do some work honestly, because we can hook the messages in the window through the window subclass Technology (subclassing. Visual Studio plug-ins work in the IDE's process space, which gives us the opportunity to hook any windows in the IDE. Theoretically, we can use our own window message processing process to replace the standard window message processing process of each window in IDE to complete the response to a specific message, or even completely change the behavior of a window. The famous VC commercial plug-in visual assist replaces the View window of document editing, so that it provides more convenient functions than the default document editing window.
There are many windows in the Visual Studio IDE environment. We only care about three (class) windows, one is the main framework window, the other is the MDI sub-framework window, and the other is the document window. In fact, the tab bar of tabbars does not depend on messages in the main framework window to constrain their behaviors. The main framework window of subclass is mainly used to process wm_gettext messages. When you switch between different document windows, the text displayed in the title bar of the main frame window is changed accordingly, the hook wm_gettext message enables the tabbars plug-in to obtain and process the message in the first time. The child frame window of Child-type MDI has two main purposes: one is to intercept the window size and position change messages so that the size and position of the tab bar can be adjusted in a timely manner; the other is to report the location of the new customer area in the MDI sub-Framework Window to the document window. The positions occupied by the tab bar window are excluded from the new customer area. If the message is not processed, the Framework Window will display the document window according to the default position, which will block the tab window. The subclass document window is used to process the wm_destroy message, so that you can update the button in the tag bar when closing the document window. Is the relationship diagram of the window class of the tabbars plug-in:

Figure 1. tabbars window class relationship diagram

The core of the relationship diagram is the ctabmanagerwindow class. Although this class is named tabmanager, it does not directly manage the label bar. It manages the label bar through ctabbarswnd. Ctabbarswnd is a cwnd derived class of MFC. It has two functions. One is periodic timer events, and the tabbars plugin is used to automatically save files; another function is to host a table control as a container window.

The key to subclass windows is to find the window handle. The built-in plug-in interface of Visual Studio does not provide the method to obtain these window handles. tabbars uses many small trick methods to achieve this purpose, the first is the hook main framework window. first look at the following code:

PAPP-> put_active (variant_false );
PAPP-> put_active (variant_true );
Hwnd =: getactivewindow ();
While (hwnd & hwnd! = Hsf-topwnd)
{
Hdevstudiownd = hwnd;
Hwnd =: getparent (hwnd );
}
G_pdevstudiownd = new cdevstudiownd (hdevstudiownd); // cwnd: fromhandle (hdevstudiownd );

Put_active is the active attribute of the iapplication interface. Make sure that the IDE window of Visual Studio is the current active window and call getactivewindow to obtain the window. However, getactivewindow usually gets the activity sub-window in IDE, so you can get the real main frame window by looking up the parent window.

After obtaining the main frame window, you can get the MDI child frame window. The MDI child frame window uses a fixed Class Name: mdiclient, you can find the MDI customer window by traversing all the subwindows of the main frame window:

Char cclassname [256];

Hmdiwnd = g_pdevstudiownd-> gettopwindow ()-> m_hwnd;
: Getclassname (hmdiwnd, (lptstr) cclassname, sizeof (cclassname ));
While (strcmp (cclassname, "mdiclient ")! = 0)
{
Hmdiwnd =: getnextwindow (hmdiwnd, gw_hwndnext );
Assert (hmdiwnd );
Getclassname (hmdiwnd, (lptstr) cclassname, sizeof (cclassname ));
}

Subclass these key windows so that the window created by the tabbars plug-in can hook appropriate messages. By responding to these messages, the tabbars plug-in can adjust the position of the tab bar, update the tab bar and notify other windows of changes to the MDI customer area, so that the tabbars window can be integrated into the integrated development environment (IDE) of Visual Studio.