Thanks Christian!

Thanks Rocky, That did the trick.

You're welcome :). Don't worry about it. I had to ask as well :). Ryan Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge) Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"

V. useful outlook resource. http://www.slipstick.com/index.htm

ke5in wrote: Q1: Is encapsulating the thread in the class like this bad practice? Not particularly, but why not have a seperate class containing an event, replace the ManualRaiseEvent with this class and then have an event handler in your Worker class? I tend to believe in threading when I want two things to happen simultaneously (maybe if your Worker thread was continuously updating a database or an on-screen display while the program was off doing something else) rather than just waiting for something to happen. That's what events are for. ke5in wrote: Q2: Assuming that there is nothing wrong with encapsulating the thread, is there anyway I can terminate it in a destructor? I would like to see this thread die when the instance of the class goes out of scope. I think explicitly calling the kill method is lame. (Or do I just have to get used to the way things are destroyed in C#?) Nothing wrong with doing it this way... you might want to call it "Dispose" though, that's the C#/VB.NET standard for killing something without waiting for it to be deconstructed. ke5in wrote: Q3: What is the “approved” method of waiting for a thread to start? i.e. is there anything better than this: while(t.ThreadState == ThreadState.Unstarted){} Seems like a good method to me. You might want to Sleep(10) in the loop though, just so other programs can get at your processor while you're waiting. Paul

I tried emailing this but just got a bounce-back in return: > In C# I can create a class for a thread and get it running. > But the thing that has me confused is the “event” which > occurs in the application. How do I notify the thread that > this “event” has occurred using “the event architecture that > .NET already provides”? Here is how I would set it up (ignore capitalization, I'm typing in outlook so it likes to 'correct' me). There are two different ways of doing this, the first is used if its just a notification that something happened ("I was clicked", "I finished processing the task you already know about", etc), the second is used if you need to supply some data to the listener. First the notification method: class MyThread : .... { // other members public event EventHandler MyEvent; protected virtual void OnMyEvent(EventArgs e) { FireMyEvent(e); } private void FireMyEvent(EventArgs e) { if( MyEvent != null ) { MyEvent(this, e); } } private void SomeCode() { SomeLengthyProcessing(); SomeMoreProcessing(); // MyEvent occurred let everyone know OnMyEvent(EventArgs.Empty); EvenMoreProcessing(); } } Now in the code that needs to receive that event: ..... MyThread mt = new MyThread(); // attach event listner mt.MyEvent += new EventHandler(myMethodToExecuteWhenMyEventHappens); ..... private void myMethodToExecuteWhenMyEventHappens(object sender, EventArgs e) { // Code to execute when MyEvent occurs } In the cases where you have data to be returned you use the same pattern, but the type names change a bit class MyEventEventArgs : EventArgs { // data members private int myValue; public MyEventEventArgs( /* arguments */ int myValue ) { // set data members this.myValue = myValue; } public int MyValue { get { return myValue; } } } class MyThread : .... { // other members public delegate void MyEventEventHandler(object sender, MyEventEventArgs e); public event MyEventEventHandler MyEvent; protected virtual void OnMyEvent(MyEventEventArgs e) { FireMyEvent(e); } private void FireMyEvent(MyEventEventArgs e) { if( MyEvent != null ) { MyEvent(this, e); } } private void SomeCode() { SomeLengthyProcessing(); SomeMoreProcessing(); // MyEvent occurred let everyone know MyEventEventArgs e = n

When you develop an entreprise product and big customers tell you to port a Windows app to Unix, your skills are speed and capabilities to port to this platform. Interoperability would normally mean that porting would be eased. I don't really see the point between this interoperability - from the real world - and the words interoperable that I see in MSDN doc. As long as you aren't in this process, the greatest way to ensure the capabilities to do it, is to stay informed. It is very hard these days to share marketing versus true technology behind the .Net strategy. Regarding DirectX, of course I wouldn't fight and say DirectX is not used. Of course, it is, and it's used by 99.99% of Windows games. I mean it is a failure because at the basis of the Game SDK, there should have been implementation which, for each feature, either were taking advantage of hardware, or were implementing it through software. Thanks to this paradigm, the DirectX was to be a tunnel were all games would run. May be slower if software was used instead of hardware. What happened to that ? I have bought games that I have never been able to run. At least 3 / 4 of game trials fall in this too.