Hi Yuri,
Yuri Dario wrote:
Hi Philipp,
Actually I think you're quite wrong here :-) SendMessage will call the
WinProc directly in the other thread (switching to that thread, or so
says the msdn documentation). The solar mutex is not involved here
I don't think SendMessage will switch thread: if you execute
sendmessage from thread#2, the window procedure will be executed in
thread#2. This was true in earlier windows versions, but should be
still true for backward compatibility.
So I am no Win32 API expert at all, the documentation states, that
messages send on behalf of "SendMessage" are dispatched to the thread,
which created the window, which's hwnd had been passed, which actually
must call one of the "message related" Win32 APIs, to actually receive
the message ... these types of message are called "non-queued" messages.
here is that all of vcl's system windows must be created on one thread
(the main thread) or several operations will silently fail - things like
drawing, clipboard, DnD, OLE and the like ;-). Or so I was told (being
usually the thread must be the same, but given the difficult to create
windows in differents threads and keep track of them, it results more
easier to handle messaging in thread 1.
Ensuring the availability of a "special" thread (often known as the
"main-thread"), can IMHO not be guaranteed, in case this thread is not
under explicit control. Eventually explicitly controlling this thread is
actually the aim of the VCL thread-transparency effort
http://wiki.services.openoffice.org/wiki/Effort/Make_VCL_Thread-Transparent
OS/2 works in the same way.
Ahh, nice to know. So one can see, that MS infected it with the same
design flaws as Windows (no flame intended) ;-)
Bye,
Yuri Dario
Regards
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
