MFC浅出

SendMessage CString

玻璃小屋 — Mon, 22 Jun 2009 06:21:00 GMT

发送
CString strHello = "Hello!";
::SendMessage(this->m_hWnd,WM_1,1,*(LPARAM*)&strHello);

接收
// CdtToolsDlg 消息处理程序
LRESULT CdtToolsDlg::On1(WPARAM,LPARAM l)
{

CString strHello = *(CString*)(LPARAM*)&l;
return TRUE;
}

W2A、OLE2A等 ATL 宏会引发 stack overflow。使用时注意。

玻璃小屋 — Fri, 09 Jan 2009 01:33:00 GMT

最近一个转换文件的程序，在转换大批量文件是老是 stack overflow。
查来查去。。原来是在大循环中用了W2A和A2W两个宏。
MSDN的 TN059: Using MFC MBCS/Unicode Conversion Macros 有描述，这两个宏在大循环中要有特殊的写法，不然保不准就 stack overflow。

Other Considerations

Do not use the macros in a tight loop. For example, you do not want to write the following kind of code:

	Copy Code
void BadIterateCode(LPCTSTR lpsz) { USES_CONVERSION; for (int ii = 0; ii < 10000; ii++) pI->SomeMethod(ii, T2COLE(lpsz)); }

The code above could result in allocating megabytes of memory on the stack depending on what the contents of the string lpsz is! It also takes time to convert the string for each iteration of the loop. Instead, move such constant conversions out of the loop:

	Copy Code
void MuchBetterIterateCode(LPCTSTR lpsz) { USES_CONVERSION; LPCOLESTR lpszT = T2COLE(lpsz); for (int ii = 0; ii < 10000; ii++) pI->SomeMethod(ii, lpszT); }

If the string is not constant, then encapsulate the method call into a function. This will allow the conversion buffer to be freed each time. For example:

	Copy Code
void CallSomeMethod(int ii, LPCTSTR lpsz) { USES_CONVERSION; pI->SomeMethod(ii, T2COLE(lpsz)); } void MuchBetterIterateCode2(LPCTSTR* lpszArray) { for (int ii = 0; ii < 10000; ii++) CallSomeMethod(ii, lpszArray[ii]); }

Copy Code

void CallSomeMethod(int ii, LPCTSTR lpsz)
{
   USES_CONVERSION;
   pI->SomeMethod(ii, T2COLE(lpsz));
}

void MuchBetterIterateCode2(LPCTSTR* lpszArray)
{
   for (int ii = 0; ii < 10000; ii++)
      CallSomeMethod(ii, lpszArray[ii]);
}

Never return the result of one of the macros, unless the return value implies making a copy of the data before the return. For example, this code is bad:

	Copy Code
LPTSTR BadConvert(ISomeInterface* pI) { USES_CONVERSION; LPOLESTR lpsz = NULL; pI->GetFileName(&lpsz); LPTSTR lpszT = OLE2T(lpsz); CoMemFree(lpsz); return lpszT; // bad! returning alloca memory }

The code above could be fixed by changing the return value to something that copies the value:

	Copy Code
CString BetterConvert(ISomeInterface* pI) { USES_CONVERSION; LPOLESTR lpsz = NULL; pI->GetFileName(&lpsz); LPTSTR lpszT = OLE2T(lpsz); CoMemFree(lpsz); return lpszT; // CString makes copy }

The macros are easy to use and easy to insert into your code, but as you can tell from the caveats above, you need to be careful when using them.

MFC的一个BUG? void CHtmlView::OnDestroy() 造成的 GetActiveView()的困扰。

玻璃小屋 — Fri, 30 Nov 2007 09:16:00 GMT

标准的从CView 继承的 CMyXXXView 应该都掉用 CView::OnDestroy 做一些自己被消灭后的身后事。。如下：

void CView::OnDestroy()
{
CFrameWnd* pFrame = GetParentFrame();
if (pFrame != NULL && pFrame->GetActiveView() == this)
pFrame->SetActiveView(NULL); // deactivate during death
CWnd::OnDestroy();
}

可是我们的 CHtmlView 大侠的 OnDestroy() 却什么都没做。。。
void CHtmlView::OnDestroy()
{
}

由于以上原因，我写的 Multi Doc/View 结构中用了CHtmlView 的派生类，结果在程序退出时，在GetActiveView 中遇到访问违历。。。因为 CHtmlView 销毁时没有执行 SetActiveView(NULL);

我把我派生的 CXXHtmlView 改成：

void CHotHtmlGuXiaoView::OnDestroy()
{
CFrameWnd* pFrame = GetParentFrame();
if (pFrame != NULL && pFrame->GetActiveView() == this)
pFrame->SetActiveView(NULL); // deactivate during death

//CHtmlView::OnDestroy(); 注释。。。反正什么都没做。。。
// TODO: 在此处添加消息处理程序代码
}

是MFC的BUG？？还是我没按照MFC的流程做事？？？

不管了，反正目前问题解决了。。。。

对话框事件中循环处理数据时的消息分发~

玻璃小屋 — Fri, 03 Aug 2007 01:34:00 GMT

  while(PeekMessage(&msg, NULL, NULL, NULL, PM_REMOVE))
  {
   TranslateMessage(&msg);
   DispatchMessage(&msg);
  }

做 DLL 时 “__declspec(dllexport)” 和 “.def 文件”定义导出函数的区别（转自MSDN）

玻璃小屋 — Sun, 29 Oct 2006 13:49:00 GMT

若要确定用于导出函数的方法（.def 文件或 __declspec(dllexport) 关键字），请回答下列问题：

是否要一直添加附加的导出函数？
谁要使用 DLL？例如，是由许多无法重新生成的可执行文件使用的第三方 DLL 还是仅由可以轻松重新生成的应用程序使用的 DLL？

使用 .DEF 文件的优缺点

在 .def 文件中导出函数使您得以控制导出序号。当将附加的导出函数添加到 DLL 时，可以给它们分配更高的序号值（高于任何其他导出函数）。当您进行此操作时，使用隐式链接的应用程序不必与包含新函数的新导入库重新链接。这非常重要，例如，在设计将由许多应用程序使用的第三方 DLL 时。可以通过添加附加功能不断地增强 DLL，同时确保现有应用程序继续正常使用新的 DLL。MFC DLL 是使用 .def 文件生成的。

使用 .def 文件的另一个优点是：可以使用 NONAME 属性导出函数，该属性仅将序号放到 DLL 的导出表中。对具有大量导出函数的 DLL，使用 NONAME 属性可以减小 DLL 文件的大小。有关编写模块定义语句的信息，请参见模块定义语句的规则。有关序号导出的更多信息，请参见按序号而不是按名称从 DLL 导出函数。

使用 .def 文件的主要缺点是：在 C++ 文件中导出函数时，必须将修饰名放到 .def 文件中，或者通过使用外部“C”用标准 C 链接定义导出函数，以避免编译器进行名称修饰。

如果需要将修饰名放到 .def 文件中，则可以通过使用 DUMPBIN 工具或 /MAP 链接器选项来获取修饰名。请注意，编译器产生的修饰名是编译器特定的。如果将 Visual C++ 编译器产生的修饰名放到 .def 文件中，则链接到 DLL 的应用程序必须也是用相同版本的 Visual C++ 生成的，这样调用应用程序中的修饰名才能与 DLL 的 .def 文件中的导出名相匹配。

使用 __declspec(dllexport) 的优缺点

使用 __declspec(dllexport) 非常方便，因为不必考虑维护 .def 文件和获取导出函数的修饰名。例如，如果您设计的 DLL 供自己控制的应用程序使用，则此方法很适用。如果通过新的导出函数重新生成 DLL，还必须重新生成应用程序，因为如果使用不同版本的编译器进行重新编译，则导出的 C++ 函数的修饰名可能会发生变化。

关于MFC的CSocket和CAsyncSocket封装的一个大误解！

玻璃小屋 — Mon, 23 Oct 2006 05:51:00 GMT

说实话！开始用CSocket和 CAsyncSocket的时候觉的很好用。都是用来写客户端的嘛！比如 ftp啦，什么的。都是单线程的。
可是后来做的多了，听的多了。似乎大家都对CSocket和CAsyncSocket斥之以鼻！后来要写服务器方面的程序了连接多了，线程模式也是多线程了。查了很多资料，都说这两个封装的效率很低。似乎是每创建一个CSocket对象，都会创建一个窗口。这样的话，如果写服务器程序，几百几千个socket的话，就有几百几千的windows了。。。那就晕了。。。。。

直到某一天有了如下我老人家自以为是，最后砸了自己的脚的对话：

2006-10-23 12:39:26 周伯通
CAsyncSocket的OnSend,OnSend等会重入吗？

2006-10-23 12:40:36 周伯通
[:D]

2006-10-23 12:41:17 ㊣毛毛
啥叫重入？？包的顺序混乱？

2006-10-23 12:41:30 ㊣毛毛
写服务端？还是客户端？

2006-10-23 12:42:19 周伯通
就是一个OnReceive没结束，令一个OnReceive又开始了

2006-10-23 12:42:32 周伯通
老大，你连这个都不懂？

2006-10-23 12:42:41 周伯通
我今天眼花了？

2006-10-23 12:43:45 ㊣毛毛
他是基于消息的。

2006-10-23 12:44:23 周伯通
进不进对列？

2006-10-23 12:45:05 ㊣毛毛
[:L]

2006-10-23 12:45:20 周伯通
[:D]

2006-10-23 12:45:35 周伯通
你是汉正街的水货

2006-10-23 12:45:53 ㊣毛毛
每个CAsyncSocket都有一个窗口。

2006-10-23 12:46:08 周伯通
你是汉正街的水货

2006-10-23 12:46:28 ㊣毛毛
当有数据的时候，socket 会发消息给这个窗口。

2006-10-23 12:47:01 周伯通
每个调用了AfxSockInit的线程都只有一个窗口！

2006-10-23 12:47:23 周伯通
五年前我最喜欢哪这个问题考别人

2006-10-23 12:47:35 ㊣毛毛
我真晕。。。

2006-10-23 12:47:40 周伯通
[:D]

2006-10-23 12:48:31 周伯通
1000个连接要是有1000个隐藏窗口，硬件厂商就高兴了

2006-10-23 12:48:36 周伯通
[:D]

2006-10-23 12:49:51 周伯通
你是开发人员？还是冒牌的？

2006-10-23 12:49:55 周伯通
[:D]

2006-10-23 12:50:04 ㊣毛毛
唉。

2006-10-23 12:50:41 周伯通
[:P]

2006-10-23 12:52:03 周伯通
别生气，开个玩笑

2006-10-23 12:54:06 周伯通
{5CBB6

2006-10-23 13:02:55 周伯通
伤心了？

2006-10-23 13:03:00 周伯通
自卑了？

2006-10-23 13:08:06 周伯通
I am sorry!

2006-10-23 13:09:33 ㊣毛毛
刚刚查了半天代码。。应该是每个线程一个窗口！

2006-10-23 13:09:49 ㊣毛毛
每个有 CSocket的线程！

2006-10-23 13:10:01 周伯通
也不一定

2006-10-23 13:10:09 ㊣毛毛
应该是的。

2006-10-23 13:10:29 周伯通
关键是看该线程是否调用AfxSockInit

2006-10-23 13:11:03 ㊣毛毛
。。。不调用根本就不能用 socket 函数 -.-

2006-10-23 13:11:26 周伯通
取决与AfxSockInit创建的一个数据结构，就是那个我特烦的模块线程状态

2006-10-23 13:11:54 周伯通
因为有人可能只在主线程中Call sockInit

2006-10-23 13:13:43 周伯通
我不知道这样做现在还可不可以！！

2006-10-23 13:14:02 周伯通
Long Long ago是可以的

2006-10-23 13:16:31 ㊣毛毛
按他的模式，是每个线程都有一个 socket wnd..

2006-10-23 13:16:58 周伯通
对

2006-10-23 13:17:08 周伯通
但他又。。

2006-10-23 13:17:17 周伯通
唉

2006-10-23 13:17:26 周伯通
不清不白

。。。所以结论应该是：不是创建一个新的CSocket对象就要创建一个新的窗口。而是同一个线程里面的 CSocket对象共享一个m_hSocketWindow。所以这样看来，我以前的每个CSocket一个窗口的想法就错了，所以按此想法推理的CSocket写服务器程序效率的结论似乎也占不住脚！CSocket应该还是不错的封装！效率差在什么地方？？差在低层消息循环的开销？可是其他模型在实际工程中的同步什么的开销也应该不少吧？？请路过的老鸟指教？？

另外线程数据的结构如下，摘自afxstat_.h

// AFX_MODULE_THREAD_STATE (local to thread *and* module)
class AFX_MODULE_THREAD_STATE : public CNoTrackObject
{
public:
AFX_MODULE_THREAD_STATE();
virtual ~AFX_MODULE_THREAD_STATE();

// current CWinThread pointer
CWinThread* m_pCurrentWinThread;

// list of CFrameWnd objects for thread
CTypedSimpleList<CFrameWnd*> m_frameList;

// temporary/permanent map state
DWORD m_nTempMapLock; // if not 0, temp maps locked
CHandleMap* m_pmapHWND;
CHandleMap* m_pmapHMENU;
CHandleMap* m_pmapHDC;
CHandleMap* m_pmapHGDIOBJ;
CHandleMap* m_pmapHIMAGELIST;

// thread-local MFC new handler (separate from C-runtime)
_PNH m_pfnNewHandler;

#ifndef _AFX_NO_SOCKET_SUPPORT
// WinSock specific thread state
HWND m_hSocketWindow;
#ifdef _AFXDLL
CEmbeddedButActsLikePtr<CMapPtrToPtr> m_pmapSocketHandle;
CEmbeddedButActsLikePtr<CMapPtrToPtr> m_pmapDeadSockets;
CEmbeddedButActsLikePtr<CPtrList> m_plistSocketNotifications;
#else
CMapPtrToPtr* m_pmapSocketHandle;
CMapPtrToPtr* m_pmapDeadSockets;
CPtrList* m_plistSocketNotifications;
#endif
#endif

// common controls thread state
CToolTipCtrl* m_pToolTip;
CWnd* m_pLastHit;       // last window to own tooltip
INT_PTR m_nLastHit;         // last hittest code
TOOLINFO* m_pLastInfo;    // last TOOLINFO structure
INT_PTR m_nLastStatus;      // last flyby status message
CControlBar* m_pLastStatus; // last flyby status control bar
};

世上好人多。MFC、对话框的一些技巧（转）

玻璃小屋 — Thu, 28 Sep 2006 06:24:00 GMT

http://dtor.cnblogs.com/archive/2006/07/13/449957.html

关掉 vs2005 的 64位 time_t 的选项 _USE_32BIT_TIME_T

玻璃小屋 — Thu, 30 Mar 2006 05:57:00 GMT

升级老代码会用到吧。

(ZT)How To Know When the User Clicks a Check Box in a TreeView Control

玻璃小屋 — Thu, 23 Feb 2006 01:18:00 GMT

CSplitterWnd!?

玻璃小屋 — Fri, 29 Apr 2005 01:42:00 GMT

今天想分割一下窗口，没有用 Doc/View 结构~ 想用CSplitterWnd 分割出一个继承自 CTreeCtrl的窗口和一个继承自 CWnd 的窗口。

在 CSpliterWnd 的父窗口的 OnCreate 中调用

int CChildView::OnCreate(LPCREATESTRUCT lpCreateStruct)
{

// 创建拆分器窗口
if (!m_wndSplitter.CreateStatic(this, 1, 2))
return -1;

if (!m_wndSplitter.CreateView(0, 0, RUNTIME_CLASS(CHotTreeCtrl), CSize(200, 200), NULL) ||
  !m_wndSplitter.CreateView(0, 1, RUNTIME_CLASS(CHotVtPain), CSize(100, 100), NULL))
{
  DWORD nRet = GetLastError();
  m_wndSplitter.DestroyWindow();
  return -1;
}

return 0;
}

编译成功。可是运行时创建出来的Pane(0,0)不是 CTreeCtrl ，而是普通的CWnd~~~，晕死，也许是对MFC了解不够，于是后来就查了查CSplitterWnd::CreateView这个成员函数的代码：

/////////////////////////////////////////////////////////////////////////////
// CSplitterWnd default creation of parts

// You must create ALL panes unless DYNAMIC_SPLIT is defined!
// Usually the splitter window is invisible when creating a pane
BOOL CSplitterWnd::CreateView(int row, int col,
CRuntimeClass* pViewClass, SIZE sizeInit, CCreateContext* pContext)
{
#ifdef _DEBUG
ASSERT_VALID(this);
ASSERT(row >= 0 && row < m_nRows);
ASSERT(col >= 0 && col < m_nCols);
ASSERT(pViewClass != NULL);
ASSERT(pViewClass->IsDerivedFrom(RUNTIME_CLASS(CWnd)));
ASSERT(AfxIsValidAddress(pViewClass, sizeof(CRuntimeClass), FALSE));

if (GetDlgItem(IdFromRowCol(row, col)) != NULL)
{
  TRACE(traceAppMsg, 0, "Error: CreateView - pane already exists for row %d, col %d.\n",
   row, col);
  ASSERT(FALSE);
  return FALSE;
}
#endif

// set the initial size for that pane
m_pColInfo[col].nIdealSize = sizeInit.cx;
m_pRowInfo[row].nIdealSize = sizeInit.cy;

BOOL bSendInitialUpdate = FALSE;

CCreateContext contextT;
if (pContext == NULL)
{
  // if no context specified, generate one from the currently selected
  // client if possible
  CView* pOldView = (CView*)GetActivePane();
  if (pOldView != NULL && pOldView->IsKindOf(RUNTIME_CLASS(CView)))
  {
   // set info about last pane
   ASSERT(contextT.m_pCurrentFrame == NULL);
   contextT.m_pLastView = pOldView;
   contextT.m_pCurrentDoc = pOldView->GetDocument();
   if (contextT.m_pCurrentDoc != NULL)
    contextT.m_pNewDocTemplate =
      contextT.m_pCurrentDoc->GetDocTemplate();
  }
  pContext = &contextT;
  bSendInitialUpdate = TRUE;
}

CWnd* pWnd;
TRY
{
  pWnd = (CWnd*)pViewClass->CreateObject();//这里是动态 new 一个你传进来的窗口类的实例！！！
  if (pWnd == NULL)
   AfxThrowMemoryException();
}
CATCH_ALL(e)
{
  TRACE(traceAppMsg, 0, "Out of memory creating a splitter pane.\n");
  // Note: DELETE_EXCEPTION(e) not required
  return FALSE;
}
END_CATCH_ALL

ASSERT_KINDOF(CWnd, pWnd);
ASSERT(pWnd->m_hWnd == NULL); // not yet created

DWORD dwStyle = AFX_WS_DEFAULT_VIEW & ~WS_BORDER;

// Create with the right size (wrong position)
CRect rect(CPoint(0,0), sizeInit);
//值得注意的是这里，它实际上调用的是 CWnd的 Create来创建普通窗口！！而不是掉用的我们继承的CTreeCtrl 的 CHotTreeCtrl 的Create来创建 “SysTreeView“ 类型的窗口！！！所以就没有办法在 pane(0,0)中创建出树型控件了！！！！可是人家 MFC 的 Doc/view 结构可以正常啊~~ 于是还是要查MFC源代码！！！
if (!pWnd->Create(NULL, NULL, dwStyle,
  rect, this, IdFromRowCol(row, col), pContext))
{
  TRACE(traceAppMsg, 0, "Warning: couldn't create client pane for splitter.\n");
   // pWnd will be cleaned up by PostNcDestroy
  return FALSE;
}
ASSERT((int)_AfxGetDlgCtrlID(pWnd->m_hWnd) == IdFromRowCol(row, col));

// send initial notification message
if (bSendInitialUpdate)
pWnd->SendMessage(WM_INITIALUPDATE);

return TRUE;
}

上面提到还是从MFC 源代码入手于是就找 CTreeView的代码！
//CTreeView 的构造函数如下！其中：WC_TREEVIEW 就是字符串“SysTreeView32”
_AFXCVIEW_INLINE CTreeView::CTreeView() : CCtrlView(WC_TREEVIEW,
AFX_WS_DEFAULT_VIEW)
{ }
好！我们继续找 CCtrlView 的代码！-_-
下面的CCtrlView的构造函数，实际上把 “SysTreeView32” 传给了 m_strClass，然后我们注意 CtreeView::PreCreateWindow 成员函数中它又： cs.lpszClass = m_strClass，到这里就真象大白了，原来 MFC 利用 CSplitterWnd 是用窗口的 PreCreateWindow 来改变窗口注册类的！！！

CCtrlView::CCtrlView(LPCTSTR lpszClass, DWORD dwStyle)
{
m_strClass = lpszClass;
m_dwDefaultStyle = dwStyle;
}

BOOL CCtrlView::PreCreateWindow(CREATESTRUCT& cs)
{
ASSERT(cs.lpszClass == NULL);
cs.lpszClass = m_strClass;

// initialize common controls
VERIFY(AfxDeferRegisterClass(AFX_WNDCOMMCTLS_REG));
AfxDeferRegisterClass(AFX_WNDCOMMCTLSNEW_REG);

// map default CView style to default style
// WS_BORDER is insignificant
if ((cs.style | WS_BORDER) == AFX_WS_DEFAULT_VIEW)
cs.style = m_dwDefaultStyle & (cs.style | ~WS_BORDER);

return CView::PreCreateWindow(cs);
}

于是我们重载了 CHotTreeCtrl 的 PreCreateWindow 函数！

BOOL CHotTreeCtrl::PreCreateWindow(CREATESTRUCT& cs)
{
// TODO: 在此添加专用代码和/或调用基类
cs.lpszClass = WC_TREEVIEW;
cs.style |= TVS_SHOWSELALWAYS | TVS_SINGLEEXPAND;// | TVS_HASLINES | TVS_HASBUTTONS | TVS_LINESATROOT;
return CTreeCtrl::PreCreateWindow(cs);
}

OK~~~ TreeCtrl 成功创建了！！！！ MFC~~ 想说爱你不容易!