The only way this can happen is if you, or some other logic, gives control
back to the message pump by calling Application.DoEvents. But, this still
occurs on a single thread. Each message is processed completely unless it
gives up control using DoEvents. That is why when you use DoEvents you need
to be careful because you can have re-entrancy problem. You need to add your
own state control in your application to manage this.
"Boni" wrote:
Dear John,
unfortunately the multithreading problems do happen. I see that MouseMove
call overlapes with OnPaint call of the same control.
Sometimes mousemove is not finished where OnPaint is already started.
Is there any solution for that?
Thanks in advance,
Boni
"TrtnJohn" <Tr******@discussions.microsoft.com> schrieb im Newsbeitrag
news:32**********************************@microsof t.com... Windows messages are received and dispatched from the main UI thread so
typically you do not have multithreading problems unless your application
is
calling these methods directly from a different thread. If so, you need
to
be sure to use Control.Invoke and pass a delegate instead of calling the
methods directly. Control.Invoke will marshall all of your calls to the
main
UI thread instead of from your worker thread.
"Boni" wrote:
Dear all,
I do need to lock a not thread-safe object from multiple access. This
object
is accessed in OnPaint,MouseMove,MouseUp,MouseDown.
SyncLock seems to not work(?) because event hadlers are not
threads(?).Please give me solution advice.
Thanks in advance.
Boni
