Re: vb .net and dataqueue question

Thanks Walden. I am now venturing into places un-discovered to me, but I
will do as you suggest.

I took the multi-thread approach mainly because I wasn't sure another way of
doing what I want. The sample I gave was a simple one. The actual app does a
lot more.

Basically, I want to have a data queue waiting on a request from the user,
then act on that request. The requests can be as simple as showing a web
page (in the browser, not using the web control), or using a custom control
that allows dropping emails into certain folders.

Do you have different suggestions on how this could be done?

Thanks again.

Tim.

-----Original Message-----
From: systemidotnet-bounces@xxxxxxxxxxxx
[mailto:systemidotnet-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Monday, November 03, 2008 3:24 PM
To: .net use with the System i
Subject: Re: [SystemiDotNet] vb .net and dataqueue question

Tim,

I can see a couple of problems. Take a look at the comments in my sample
code.

First, COM objects must be run in a STA (Single Threaded Apartment)
thread, by default threads are MTA (Multi-Threaded Apartment). You need
to set the AparementState on any thread that will use COM. Running COM
in MTA threads is, um, unpredictable. :-)

Second, you cannot access a UI element from a thread other than the one
that created it, and remember the form itself is a UI thread. I would
.Invoke() the data back into the UI thread and then set lbl1 and brweb
from there. Why did you create the browser on its own thread? Just
create the browser on the base UI thread.

And please look into log4net or some other logging infrastructure and
use it in your code. Debugging a multi-threaded app is very difficult
since the act of debugging must suspend threads and that changes the
dynamic of the runtime. Also, if you can, test your app on true
multi-core/multi-proc machines.

-Walden