Each time when you use a win32 API which uses a HANDLE remember that the handle Must be valid (not closed). It is important to understand the concepts of the handle being signaled and being closed. Signaled state refers to the handle state. It can be signaled or unsignaled. Wait functions for example, like WaitForSingleObject, block current thread until the object gets signaled. A handle is said to be closed when its reference count reaches zero value. When this happens the handle is closed and doing any waiting on it is error prone. A handle is a pointer on an object. Wait functions check the state of the object, hence it is a must that the handler (the pointer) is valid. Otherwise, waiting functions wont work properly (while waiting on an invalid handle, you might wait indefinetly). One example of bogus use is with MFC AfxBeginThread function. Its default behaviour is to auto 'delete' the thread, i.e to close its handle. Its bad to use the returned handle after the thread is ...

When you dealing with multithreading in your code, every data you use in more than one thread it should be a subject to your attention in the way its used in those threads. Similary, using GDI objects in multithreading does not require any special code beside some (natural) common-sense 'not to do' things, which is, dont read and modify un-synchronized in the same time. Also, remember that they have thread affinity (the thread which created the object should be the one who deletes it). The following text is from the Raymond Chen wonderful blog: Window objects: thread which created the window its said to be the window 'owner'. Messages are dispatched to a window procedure only on the thread that owns it, and generally speaking, modifications to a window should be made only from the thread that owns it. Although the window manager permits any thread to access such things as window properties, styles, and other attributes such as the window procedure, and such accesses ar...

ok, here is my task: i have a dialog (main thread) and i have a worker thread running which updates a progressbar on the GUI. when i press the close button i want the main thread and the worker thread to end cleanly (i want tthe threads to be closed nicely, without any TerminateThread or anything) now, the problem stay in the fact that when i signal (using an event or something) the worker thread to end and then wait for it to end (using WaitForSingleObject for example) it is possible that in this time the worker thread to send a message to the GUI to update the progressbar(using SendMessage). Now, some may say why that SendMessage is a mistake but maybe not. I want to be sure that the GUI and worker are synchronized perfectly (i dont want to use PostMessage; in some situations, for example when a buffer is needed to be sent, PostMessage only will not work (the buffer needs to be available when the message arrive to the receiver queue), hence, for PostMessage, some queue mechanism migh...