Thaddy, Please tell MS that my code must be a failed because I READ the control handle, Not write, just read and Post messages to main threads from secondary threads with no issue. Been working for years.
Consider yourself lucky then.
If a worker thread DIRECTLY reads a control's Handle property each time it wants to post a message, that is not safe to do across thread boundaries, it carries a dangerous race condition that you have simply been fortunate enough to not have triggered yet.
Each time a control's Handle property is read, it checks if the control's window exists, and if not then creates it. If the control's window is in the process of being (re)created at the same time that the thread reads the Handle property, it is possible for 2 new HWNDs to get created, one by the UI thread and one by the worker thread. One of those HWNDs will be leaked, and if the HWND that is created by the worker thread ends up being the one assigned to the control, then the control will stop responding, and will then later crash during future window recreations, or during app shutdown, when the UI thread tries to destroy a window it doesn't own and raises an exception because DestroyWindow() fails.
On the other hand, if you read the control's Handle property one time and then copy that HWND to the thread and use it for posting, then there is no race condition. If the control's window is ever destroyed then the thread's HWND will simply become invalid and subsequent posts will fail with error 1400 (ERROR_INVALID_WINDOW_HANDLE) until you update the thread with a new HWND after the control's window has been recreated.