宏bug

非常好的一篇文章：：

Codejock的界面库Xtreme Toolkit Pro(XTP)是当前MFC开发中发展得比较成熟，应用也颇为广泛的几个界面库之一，其强大的界面美化功能以及简便的使用步骤深受不少MFC程序员的青睐。应用XTP进行MFC程序的开发能够在极大地减少开发周期的前提下，编写出专业化的windows程序界面。

笔者在实际使用XTP的过程中，发现了一个隐藏得比较深的、一般的应用不会遇到的bug。概括地说，这个bug是与视图的静态拆分 (CXTSplitterWnd)以及标签式视图(CXTTabView)相关的，当混合使用这两个特性时，就有可能遇到这个潜在的bug。

首先让我来描述一下触发这个bug的过程：在一个基于MFC的单文档程序中使用CXTSplitterWnd将主视图拆分为左右两个视图，再在右边的视图（直接从CXTTabView继承）中创建Tab View，如果创建了多个Tab View，当激活第2个（从0开始）以上的Tab View后，此时若调用CXTSplitterWnd的HideColumn将左边的视图（非Tab View所在的主视图）隐藏，就会发生断言失败的错误。断言失败对话框会显示在MFC的源代码winsplit.cpp中的第361行出错，即在这个函数中：

view plain

1. BOOL CSplitterWnd::IsChildPane(CWnd* pWnd, int* pRow, int* pCol)  
2. {  
3.     ASSERT_VALID(this);  
4.     ASSERT_VALID(pWnd);  
5.     UINT nID = _AfxGetDlgCtrlID(pWnd->m_hWnd);  
6.     if (IsChild(pWnd) && nID >= AFX_IDW_PANE_FIRST && nID <= AFX_IDW_PANE_LAST)  
7.     {  
8.         if (pRow != NULL)  
9.             *pRow = (nID - AFX_IDW_PANE_FIRST) / 16;  
10.         if (pCol != NULL)  
11.             *pCol = (nID - AFX_IDW_PANE_FIRST) % 16;  
12.         ASSERT(pRow == NULL || *pRow < m_nRows);  
13.         ASSERT(pCol == NULL || *pCol < m_nCols);   // 在此行断言失败，行C  
14.         return TRUE;  
15.     }  
16.     else  
17.     {  
18.         if (pRow != NULL)  
19.             *pRow = -1;  
20.         if (pCol != NULL)  
21.             *pCol = -1;  
22.         return FALSE;  
23.     }  
24. }  

当出现断言失败时，我们通常的调试方法就是看调用堆栈，看到底是哪行代码出的问题。通过查看调用堆栈，我们可以清楚的看到在原因出在CXTSplitterWnd的HideColumn中的GetActivePane那一行。

view plain

1. void CXTSplitterWnd::HideColumn(int nColHide)  
2. {  
3.     ASSERT_VALID(this);  
4.     if (m_nHiddenCol != -1)  
5.     {  
6.         // return if the requested one is hidden  
7.         if (m_nHiddenCol == nColHide)  
8.         {  
9.             return;  
10.         }  
11.         ShowColumn();  
12.     }  
13.     ASSERT(m_nCols > 1);  
14.     ASSERT(nColHide < m_nCols);  
15.     ASSERT(m_nHiddenCol == -1);  
16.     m_nHiddenCol = nColHide;  
17.   
18.     // if the column has an active window -- change it  
19.     int nActiveRow, nActiveCol;  
20.     if (GetActivePane(&nActiveRow, &nActiveCol) != NULL)    // 行A  
21.     {  
22.         if (nActiveCol == nColHide)  
23.         {  
24.             if (++nActiveCol >= m_nCols)  
25.                 nActiveCol = 0;  
26.             SetActivePane(nActiveRow, nActiveCol);  
27.         }  
28.     }  
29.   
30.     // hide all column panes  
31.     /// ...  
32. }  

跟踪GetActivePane的调用，看到如下代码：

view plain

1. CWnd* CSplitterWnd::GetActivePane(int* pRow, int* pCol)  
2.     // return active view, NULL when no active view  
3. {  
4.     ASSERT_VALID(this);  
5.   
6.     // attempt to use active view of frame window  
7.     CWnd* pView = NULL;  
8.     CFrameWnd* pFrameWnd = EnsureParentFrame();  
9.     pView = pFrameWnd->GetActiveView();  
10.   
11.     // failing that, use the current focus  
12.     if (pView == NULL)  
13.         pView = GetFocus();  
14.   
15.     // make sure the pane is a child pane of the splitter  
16.     if (pView != NULL && !IsChildPane(pView, pRow, pCol))    // 行B  
17.         pView = NULL;  
18.   
19.     return pView;  
20. }  

从上面的堆栈跟踪可以很清楚地看到程序的执行路径和逻辑：调用HideColumn后，程序会检查当前将要隐藏的pane中是否存在当前的活动视图，通过调用GetActivePane（行A）来获得当前活动视图所在的行号和列号。在函数GetActivePane中会获得pFrameWnd的当前活动视图并调用IsChildPane来检查当前活动视图是否属于拆分器中的子窗格。而就在行B所示的IsChildPane这个函数中失败了，通过在调试状态下的观察，可以看到是因为行C中*pCol < m_nCols的值为false，所以导致的断言失败。

那么*pCol和m_nCols到底代表着什么含义呢，*pCol是由当前窗格的ID与AFX_IDW_PANE_FIRST宏的值计算得出的，那么为什么*pCol < m_nCols的值为false？要想搞清楚这个问题，就必须知道AFX_IDW_PANE_FIRST的含义。

查看MFC的源代码，找到AFX_IDW_PANE_FIRST宏的定义：

view plain

1. #define AFX_IDW_PANE_FIRST              0xE900  // first pane (256 max)  

以及与之对应的另一个宏：

view plain

1. #define AFX_IDW_PANE_LAST               0xE9ff  

这两个宏定义了静态拆分窗口ID的区间，即从AFX_IDW_PANE_FIRST(59648)到AFX_IDW_PANE_LAST(59903)的这样一个左闭右开的区间。所有的静态拆分窗格pane的ID均在这两个宏定义的数字之间，一共256个可用的ID号，亦即一共能够拆分为256个pane。同时我们也能够了解到由于窗口拆分的规则性，所以静态拆分器能够拆分的窗格是一个16×16的矩阵。

明白了上述原理后，回头再看看*pCol和m_nCols以及行C附近的代码，不难明白*pCol指的是当前列的列号，由当前的ID除以16后的余数得到（即求“模”），而m_nCols则表达了当前的列的个数，可以从MFC源码中的CreateStatic、SplitColumn、DeleteColumn等函数中被赋值的过程推断得出。正常情况下*pCol的值肯定是要小于m_nCols的（由于列号从0开始），当出现*pCol的值大于或者等于m_nCols时，就会导致断言失败。

上述的分析似乎很显而易见，逻辑上也很明了，但大家不禁会问：“为什么当前列号会大于等于列数呢？”这得看CXTTabView中的tab在创建的时候到底做了什么，来看源码，见XTP源码中的XTTabBase.cpp文件：

view plain

1. CWnd* CXTTabExBase::CreateTabView(CRuntimeClass* pViewClass,   
2.          CDocument* pDocument, CCreateContext* pContext)  
3. {     
4.     /// ...   
5.   
6.     int nTab = (int)m_tcbItems.GetCount();    
7.     // Create with the right size (wrong position)    
8.     CRect rect(0, 0, 0, 0);   
9.     if (!pWnd->Create(NULL, NULL, dwStyle,         
10.             rect, m_pTabCtrl, (AFX_IDW_PANE_FIRST + nTab), pContext))     
11.     {         
12.         TRACE0("Warning: couldn't create client tab for view./n");        
13.         // pWnd will be cleaned up by PostNcDestroy       
14.         return NULL;      
15.     }     
16.     if (pWnd->m_hWnd == NULL)          
17.     return NULL;      
18.   
19.     ASSERT((int)_AfxGetDlgCtrlID(pWnd->m_hWnd)   
20.                       == (AFX_IDW_PANE_FIRST + nTab));    
21.       
22.     /// ...  
23. }  

可以看出，XTP的源码实现中竟然将在TabView中嵌入的子窗口视图的ID号从AFX_IDW_PANE_FIRST开始编号？！这样的实现在TabView未作为SplitterWnd的pane时是不会出问题的，但一旦在诸如文章一开始提到的类似情境时，便会出现问题。那么，问题是怎么发生的呢？让我们来剖析剖析。

当在Mainfrm中用CreateStatic将主视图被拆分为左右两个视图时，左边的视图其ID被赋值为AFX_IDW_PANE_FIRST即59648，右边的则为59649（当非嵌套的splitterwnd时，pane的ID一般都是从AFX_IDW_PANE_FIRST开始的）。接下来在右边的pane中创建了5个tab view，分别嵌入了5个tabctrl。从上面的源码可以看出，这5个tab view的ID从59648到59652，此时，当激活第二个tabctrl（从0开始）后，此时pFrameWnd的当前活动视图即为第二个 tabctrl内嵌的视图，即59650号窗口。这样当执行前面列出的IsChildPane函数时得到的列号*pCol即为(59650-59648)%16=2，而m_nCols为2，所以此时*pCol < m_nCols不成立！！从而导致断言失败。这就是问题发生的整个过程和缘由。

从上面的分析归纳出来一句话，这是一个由于误用AFX_IDW_PANE_FIRST宏而导致的在特定情境下才会发生的潜在的bug，其根本原因是创建tabview的时候用到的ID段号占用了静态拆分器预留的ID段号，要纠正这个bug，最彻底的做法是将创建tabview时用到的ID段号与静态拆分器预留的ID段号彻底分开。幸好XTP的源码是可以由我们自己修改的，可以通过如下方法解决此bug。

重新定义一个宏XTP_IDW_TAB_FIRST，表明tabview窗格的ID起始号，并且其数值区间的选取要避开常用的一些预留ID号的区间（这些预留段号可以参见afxres.h头文件）。然后修改XTTabBase.cpp文件中的CreateTabView函数，如下：

view plain

1. CWnd* CXTTabExBase::CreateTabView(CRuntimeClass* pViewClass,   
2.       CDocument* pDocument, CCreateContext* pContext)  
3. {  
4.     /// ...  
5.   
6.     int nTab = (int)m_tcbItems.GetCount();  
7.   
8.     // Create with the right size (wrong position)  
9.     CRect rect(0, 0, 0, 0);  
10.     if (!pWnd->Create(NULL, NULL, dwStyle,  
11.         rect, m_pTabCtrl,   
12.               (XTP_IDW_TAB_FIRST + nTab), pContext))   
13.               // 修改AFX_IDW_PANE_FIRST为XTP_IDW_TAB_FIRST，D行  
14.     {  
15.         TRACE0("Warning: couldn't create client tab for view./n");  
16.         // pWnd will be cleaned up by PostNcDestroy  
17.         return NULL;  
18.     }  
19.     if (pWnd->m_hWnd == NULL)  
20.         return NULL;  
21.   
22.     ASSERT((int)_AfxGetDlgCtrlID(pWnd->m_hWnd)   
23.                      == (XTP_IDW_TAB_FIRST + nTab));  // 同D行  
24.   
25.     /// ...  
26. }  

重新编译XTP的DLL文件，再次在文章开始的情景中使用HideColumn时，一切正常。