How to Use mfcdll for Win32 programs.

For a mfcdll, it will be troublesome when it is used by Win32.

In debug mode, Win32 program assertions fail.
In the release mode, assertion is not used to operate normally.

In addition, if a worker thread calls peekmessage (), it becomes a UI thread !!!
However, there is no message in the message queue of this worker thread !!!
If the worker thread creates a window, messages delivered to the window by windows are generated in the message queue.

Remember the following theorem:
1: When and only when a thread calls several message allocation functions, such as peekmessage/getmessage and dispatchmessage (), one thread is the user interface thread. however, there is no message in the message queue of the default thread.

2: After a window is created inside the thread, or other threads have delivered messages to the thread, messages in the thread's Message Queue can be obtained.

/////////////
Solution 1:
It is not hard to understand why txdata () changes from a working thread to a UI thread. This is because,
1: cvnamewindow () creates a window,
2: cvwaitkey () internally calls message dispatch.
As a result, this worker thread has a message loop and a message.

Solution 2:
When a message is delivered to a thread with only one message and no window, the message is processed by the message processing function in that window ???
The answer is: the processing function of a window can be processed only when getmessage is used. That is, the process can be processed directly in the thread. Of course, you can still dispatch messages whose window handle is null. Then, if the thread has a window, all window handler functions want to be able to process the message. call

Confuse 3:
Sendmessage (hwnd), the first parameter is the window handle. How does a message enter the thread's message queue?
In Windows, check who created the hwnd window and put the message in the message queue of the corresponding thread.
If the message sender and receiver of sendmessage belong to two different threads, because sendmessage is synchronous, Windows will switch the context of the thread, that is, the sender's thread will lose CPU resources until the message is processed and returned.

To prevent the recipient thread from being suspended, the sender thread also fails. In Windows, the sendmessagetimeout () API is provided to specify the waiting time.