threads, forms, and com automation

[Richard Bell]

I'm working on a VB.net app that uses IE, some forms, and multiple
execution threads. I'm unclear on a couple of threading related
matters and hoped that someone could provide some insight.

From within a thread of execution, if I do a form.show, what thread
does the form process execute on? Is the form process supported by
its own thread? When the form post an event that my code catches such
as a button press, what thread does the event handler execute on? Can
I safely do a wait in the thread that does the form.show and still
handle form events such as a button press?

Similarly, from within a thread of execution, if I start a new
instance of IE what thread does it execute on? It looks to me as
though it is on its own seperate thread and process. Is this correct?
If I catch IE events such as DocumentComplete, what thread does the
event handler execute on? Can I safely do a wait in the thread that
starts IE and still handle IE events?

Thanks for any insight.

Richard

 

[Lifeng Lu]

Window resouce belongs to the thread which creates it. So when one of your
thread creates a form, the message of that window will be queued in the
message queue of that thread, and that thread will run code to handle those
messages, including the button click event.
So if that thread quits, the window will be destroyed. And if the thread is
in a loop and waiting something without processing window message. The UI
of the window will hang up, and won't response to the button press.

Did you create an IE process or just a control?

 

[Richard Bell]

Thanks, that helped.

I created an IE process, not a control. It appears to me that IE is
in its own process with its own thread(s) but that my event handlers
execute in my process. I'm not sure, however, what thread within my
process they execute on and if I can safely do a wait in the thread
that starts IE and still handle IE events?