關於win32程式如何使用mfcdll的問題.

對於一個mfcdll, 被win32使用的時候, 會出現麻煩.

在debug模式下, win32程式宣告失敗.
在release模式下, 由於沒有使用斷言, 正常運作.

另外, 一個背景工作執行緒, 如果其調用了PeekMessage() 那麼其就變成了 UI線程!!!
只不過, 由於這個背景工作執行緒的訊息佇列裡面沒有任何訊息!!!
如果這個背景工作執行緒建立了視窗, 那麼其訊息佇列裡面自然就有了windows給這個視窗投遞的訊息.

記住下面的定理:
1: 若且唯若 一個線程裡面調用了PeekMessage/GetMessage, DispatchMessage()等幾個訊息分配函數, 一個線程才是使用介面執行緒. 但是預設線程的訊息佇列裡面是沒有訊息的.

2:  當線程內部建立了一個視窗之後, 或者, 別的線程往這個線程投遞了訊息了, 線程的訊息佇列裡面才有訊息可取.

/////////////
解惑1:
不難理解為何, TXDATA()由背景工作執行緒搖身一變, 變成了UI線程. 這是因為,
1:cvNameWindow()內部建立了視窗,
2:cvWaitKey()內部調用了訊息指派.
導致這個背景工作執行緒擁有了訊息迴圈, 也擁有了訊息.

解惑2:
當向一個僅有訊息指派沒有視窗的線程投遞訊息時, 這個訊息由那個視窗的訊息處理函數處理???
答案是: 不由哪個視窗的處理函數處理, 而是在GetMessage時, 就可以處理, 也就是, 線上程裡面直接處理, 當然, 你仍然可以把該視窗控制代碼為NULL的訊息進一步 Dispatch, 然後, 如果該線程有視窗, 所有的視窗的視窗處理函數還想都能夠處理該訊息. 呼呼

解惑3:
SendMessage(HWND), 的第一個參數是視窗控制代碼, 那麼訊息怎麼進入線程的訊息佇列裡了呢?
windows內部會檢查, 這個hwnd這個視窗是有誰建立的, 然後把訊息放入對應線程的訊息佇列裡.
假如SendMessage的訊息發送方, 和訊息接收方, 屬於不同的兩個線程, 那麼由於SendMessage是同步的, windows會進行線程的環境切換, 也就是, 發送方的線程將失去CPU資源, 直到訊息被處理返回.

為了防止接收方線程掛掉, 導致發送方線程也跟著掛掉, windows提供了 SendMessageTimeout()API, 可以指定等待的時間.