Problem With Threading Using Separate Class Files

  • Thread starter Thread starter Doug Thews
  • Start date Start date
D

Doug Thews

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 said:
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.
Click to expand...

I suspect you were trying to use

new ProgressDelegate (MyForm.UpdateProgressMeter) where MyForm is the
name of the class. Instead, what you need is

new ProgressDelegate (someFormInstance.UpdateProgressMeter) where
someFormInstance is a reference to the form you want to update.

When you instantiate BusinessOperation, you need to pass it the form it
"belongs" to so that it knows what to update.
 
That sounds very plausible, and it is what I'm doing. This may be a very
stupid question, but how can I get access to the instance of the running
form when I can't pass anything to the thread that's started? I guess I
could make a public property in the BusinessOperation class that holds the
value after I instantiate the object, and then reference it from within the
delegate creation. Is this the "standard" way to do it? How would
something like this actually fix a compiler error? Wouldn't the signatures
be detected the same, thus I'd still get the error about not being a static
method?

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
 
BTW ... I did try it and it seemed to work. I saved off a ptr to the form's
class inside my business operation class, and then referenced it within the
create. It's interesting that the method signatures were the same, so I'm
still a little confused on why I got the compiler error (I would've expected
a null reference exception given the problem)

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/



Doug Thews said:
That sounds very plausible, and it is what I'm doing. This may be a very
stupid question, but how can I get access to the instance of the running
form when I can't pass anything to the thread that's started? I guess I
could make a public property in the BusinessOperation class that holds the
value after I instantiate the object, and then reference it from within
the delegate creation. Is this the "standard" way to do it? How would
something like this actually fix a compiler error? Wouldn't the
signatures be detected the same, thus I'd still get the error about not
being a static method?

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/
Click to expand...
 
It is not semantics, it is OOPS. Since the method is in another class,
you need to use an object reference to pass its address to the delegate
as below

ProgressDelegate fpr = new ProgressDelegate(ob.UpdateProgressMeter);

where ob is the instance of the class where you have declared the
method.

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
 
Doug Thews said:
That sounds very plausible, and it is what I'm doing. This may be a very
stupid question, but how can I get access to the instance of the running
form when I can't pass anything to the thread that's started?
Click to expand...

See http://www.pobox.com/~skeet/csharp/threads/parameters.html
I guess I
could make a public property in the BusinessOperation class that holds the
value after I instantiate the object, and then reference it from within the
delegate creation. Is this the "standard" way to do it?
Click to expand...

Well, there are lots of ways of passing parameters to methods, but
effectively you'll need a reference to the appropriate form
*somewhere*.
How would
something like this actually fix a compiler error? Wouldn't the signatures
be detected the same, thus I'd still get the error about not being a static
method?
Click to expand...

No, because you wouldn't be trying to access it as if it *were* a
static method.
 
Doug Thews said:
BTW ... I did try it and it seemed to work. I saved off a ptr to the form's
class inside my business operation class, and then referenced it within the
create. It's interesting that the method signatures were the same, so I'm
still a little confused on why I got the compiler error (I would've expected
a null reference exception given the problem)
Click to expand...

Why would you expect a NullReferenceException, if the reference wasn't
null?
 
Back
Top