I'm writing some sample threading code, and have already got many examples
working that look a lot similar to the ones mentioned here. What I'm seeing
is that most people put their method that will be run as a thread inside the
overall Form's class, which is OK for examples, but not really what you'd
see in real life.
So, I decided to write a class (called BusinessOperation) and have
properties & methods in it. Then, I have 1 method in it called
LongRunningBusinessOp.
So, in my Form UI code I create the thread by instantiating an object of
type BusinessOperation and then using the fpr to the LongRunningBusinessOp
to start my thread.
All works well, except when I want to use delegates to update my UI back
from LongRunningBusinessOp. For whatever reason, by moving the threaded
code outside of the Form, the compiler now says that the method (I call it
UpdateProgressMeter) I point to when creating an instance of the delegate
(not actually defining the delegate), needs to be static. This wasn't the
case before. Problem is, that if I make it static in the Form class, then
it cannot access the controls within the form.
So, what used to work:
public delegate void ProgressDelegate(string strPercentage);
private void LongRunningBusinessOp()
{
// Do code
ProgressDelegate fpr = new ProgressDelegate(UpdateProgressMeter);
// More code then call fpr.Invoke to update the status
}
Now yields a compile error (on the statement after the "//Do code" comment)
when I move the method to outside of the Form class and into it's own class
file. Like I said, all works fine if I just stuff this method and delegate
declaration back into the Form class, but that's not what I want to do.
I know it's probably something simple, like semantics, but sometimes the
obvious ones are the hardest to find when you're the closest to them.
Input would be appreciated.
--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
