Threads and Events (form oddness)

I find win forms are easiest to write if they ONLY see the primary (or
UI) thread. Thus, all events (whether buttons clicks or "ShowLabel" )
can be treated the same. This means that your clsThreadTest needs to
synchronize the events it fires which would be consumed by a form (as
you've seen on another thread). I've put comments inline on this and
other things that caught my attention.

I'd be happy for any feedback.
mike

"Drakier Dominaeus" <dr*****@cox.ne t> wrote in message
news:S2FWa.2782 3$Je.9069@fed1r ead04...

=============== ==============

namespace ThreadTest
{

<snip>

#region Test Thread
public class clsThreadTest
{

I know this is just an example, but I don't like the name of this
event. It should be named on the verb of what is happenning or
happened in this class, not the expected action of another class.
Perhaps it should be "WorkStarti ng" or such. Then the SetLabel method
should be onWorkStarting( ). I guess the form should worry about
labels, this class should worry about doing work and saying things
like "starting", "halfwaydon e", "finished", etc.

public event TestEventHandle r ShowLabel;
private bool blocked = false;
private Thread TestThread = null;
public clsThreadTest() { }

I'd write the constructor as this, to hold a reference to the form
where you will invoke synchronized events. Note, I'm using the
ISynchronizeInv oke instead of just Control to keep it generic, even
though Control implements the interface. All we care about is that
the object provided can run synchronized events. Obviously, the form
class later needs to change the instantiation of this object.
// A target to invoke events on - mrm next 6 lines
private ISynchronizeInv oke target;

public clsThreadTest( ISynchronizeInv oke target)
{
this.target = target;
}

public void SetLabel(bool bVisible)
{
if (ShowLabel != null)
{
TestEventArgs tea = new TestEventArgs(b Visible);
ShowLabel(this, tea);

We can't throw an event from this thread and have the form update
controls. BAD.
Instead, we raise the ShowLabel event using the form's invoke method
(or we could use BeginInvoke, but I think this keeps it simpler).
So instead of the above single line, we have:
object[] paramList = {this, tea};
this.target.Inv oke(ShowLabel, paramList);

}
}
public void Start()
{

The following code scares me, cause it looks like it's calling for a
race condition. It all depends on where blocked can be set and who
all can call this function. What I mean is, generally doing a single
check and then assigning the value could lead to trouble. If there
were two threads out there, thread A could check blocked, then thread
B could check blocked, then thread A could set blocked, but thread B
is already in the procedure and running. In your specific case, since
the _only_ thread that would run this code is your UI thread, it's not
a problem. Even if the user has fast fingers and can hit Start twice
in a row very quickly, that would all happen on a single UI thread so
the order of execution for that one thread would be:
button click, call start(), return from start(), return to message
loop, button click #2, call start() and find blocked is true.
I'd still be tempted to put a lock on the whole function:
lock (myLockObject)
// where myLockObject is a private object for locking on
//(e.g. private Object myLockObject)
{

if (!blocked)
{
blocked = !blocked;

i'd rewrite the above line to just assign true. I think it's what you
really mean: if we want to start and are not blocked, then block and
continue. You're not technically wanting to _reverse_ the block. (as
a start/stop toggle method might do?)

blocked = true;

TestThread = new Thread(new

ThreadStart(Run Test));

TestThread.Apar tmentState = ApartmentState. MTA;
TestThread.Prio rity = ThreadPriority. Lowest;
TestThread.Name = "Test Thread";
TestThread.Star t();
}

} // end lock(this)

}

public void Cancel()
{
blocked = false;
}

I like this method of canceling, personally (as opposed to the
ManualResetEven t). KISS. I don't see any threading problems since a
boolean is set in one autonomous write. It's also the method used by
Griffiths in an article I posted in another message on this thread.

public void RunTest()
{
while (blocked)
{
SetLabel(true);
Thread.Sleep(50 00);

I assume Thread.Sleep is where the "work" goes.

}
}
}
#endregion

public class Form1 : System.Windows. Forms.Form
{
private clsThreadTest cThreadTest;
private System.Windows. Forms.Label label1;
private System.Windows. Forms.Button button1;
private System.Windows. Forms.Button button2;
private System.Componen tModel.Containe r components = null;

public Form1()
{
InitializeCompo nent();

Need to give clsThreadTest a reference to this form.
cThreadTest = = new clsThreadTest(t his);

cThreadTest.Sho wLabel += new
TestEventHandle r(cThreadTest_S howLabel);

}

<snip>
everything else is fine by me.