From: Julie on
It looks to me like InvokeRequired() is returning an unexpected
result.

I have a multi-threaded app, and know it's a good idea to put all
functionality related to a Windows Forms control on the same thread.

I have a class which inherits from Form. When I construct an object of
this class, I print out the value for
Thread.CurrentThread.ManagedThreadId.

In all of the functions in my class, I have the same structure:

public delegate void functionNameCallback();
public void functionName()
{
if (this.InvokeRequired)
{
functionNameCallback e = new functionNameCallback(functionName);
this.Invoke(e, null);
}
else
{
// print value of Thread.CurrentThread.ManagedThreadId here
....
// do whatever work here
}
}

I can see that the thread that is calling the function is getting
"InvokeRequired" set to false; therefore, it is just doing the work
without invoking. The value for Thread.CurrentThread.ManagedThreadId
printed in the function does not match the value printed in the
constructor.

What's going on???
From: Mike Lovell on
"Julie" <julievogelman0(a)gmail.com> wrote in message
news:525d87ec-f82e-45c9-9b19-e5c4092f002d(a)q21g2000yqm.googlegroups.com...
> It looks to me like InvokeRequired() is returning an unexpected
> result.
>
> I have a multi-threaded app, and know it's a good idea to put all
> functionality related to a Windows Forms control on the same thread.
>
> I have a class which inherits from Form. When I construct an object of
> this class, I print out the value for
> Thread.CurrentThread.ManagedThreadId.
>
> In all of the functions in my class, I have the same structure:
>
> public delegate void functionNameCallback();
> public void functionName()
> {
> if (this.InvokeRequired)
> {
> functionNameCallback e = new functionNameCallback(functionName);
> this.Invoke(e, null);
> }
> else
> {
> // print value of Thread.CurrentThread.ManagedThreadId here
> ....
> // do whatever work here
> }
> }
>
> I can see that the thread that is calling the function is getting
> "InvokeRequired" set to false; therefore, it is just doing the work
> without invoking. The value for Thread.CurrentThread.ManagedThreadId
> printed in the function does not match the value printed in the
> constructor.
>
> What's going on???

Might be of help:

http://www.gotinker.com/2010/03/09/dont-shoot-the-messenger-dont-hang-the-ui/

If you're calling the function from the main thread, and at that point
checking if "InvokeRequired" (which I see you're doing) will indeed be
false. Invoke isn't required at that point. I always put my background
work in a separate thread, then use the dispatcher to talk back to the
control. I don't even bother checking InvokeRequired, because it's always
required (the way I do things!).

--
Mike
GoTinker, C# Blog
http://www.gotinker.com

From: Peter Duniho on
Julie wrote:
> [...]
> I can see that the thread that is calling the function is getting
> "InvokeRequired" set to false; therefore, it is just doing the work
> without invoking. The value for Thread.CurrentThread.ManagedThreadId
> printed in the function does not match the value printed in the
> constructor.
>
> What's going on???

Without a concise-but-complete code example, impossible to say. You
might be displaying the wrong information, or it could be that your
class really is created on a different thread. The thread that's
important is the one where the Form sub-class is shown, not where it's
instantiated.

Normally, yes�the thread ID should be the same when InvokeRequired is
false. But depending on what your code really does, you may or may not
see the same output from each location in the code.

Pete
From: Julie on
On Mar 11, 8:20 am, "Mike Lovell" <dont.re...(a)gotinker.com> wrote:
> "Julie" <julievogelm...(a)gmail.com> wrote in message
>
> news:525d87ec-f82e-45c9-9b19-e5c4092f002d(a)q21g2000yqm.googlegroups.com...
>
>
>
>
>
> > It looks to me like InvokeRequired() is returning an unexpected
> > result.
>
> > I have a multi-threaded app, and know it's a good idea to put all
> > functionality related to a Windows Forms control on the same thread.
>
> > I have a class which inherits from Form. When I construct an object of
> > this class, I print out the value for
> > Thread.CurrentThread.ManagedThreadId.
>
> > In all of the functions in my class, I have the same structure:
>
> > public delegate void functionNameCallback();
> > public void functionName()
> > {
> >   if (this.InvokeRequired)
> >   {
> >      functionNameCallback e = new functionNameCallback(functionName);
> >      this.Invoke(e, null);
> >   }
> >   else
> >   {
> >    // print value of Thread.CurrentThread.ManagedThreadId here
> >     ....
> >    // do whatever work here
> >   }
> > }
>
> > I can see that the thread that is calling the function is getting
> > "InvokeRequired" set to false; therefore, it is just doing the work
> > without invoking. The value for Thread.CurrentThread.ManagedThreadId
> > printed in the function does not match the value printed in the
> > constructor.
>
> > What's going on???
>
> Might be of help:
>
> http://www.gotinker.com/2010/03/09/dont-shoot-the-messenger-dont-hang...
>
> If you're calling the function from the main thread, and at that point
> checking if "InvokeRequired" (which I see you're doing) will indeed be
> false.  Invoke isn't required at that point.  I always put my background
> work in a separate thread, then use the dispatcher to talk back to the
> control.  I don't even bother checking InvokeRequired, because it's always
> required (the way I do things!).
>
> --
> Mike
> GoTinker, C# Bloghttp://www.gotinker.com- Hide quoted text -
>
> - Show quoted text -

Darn, I'm at work, and that website you pointed me to hasn't been
"approved" for us to go to. Any chance you could post an excerpt of it
directly on your reply? Thanks!
From: Peter Duniho on
Mike Lovell wrote:
> [...] I don't even bother checking InvokeRequired, because it's
> always required (the way I do things!).

And redundant even if it's not. I thought I'd previously shared my rant
with the OP in a previous message thread, but just in case, here's the link:
http://msmvps.com/blogs/duniho/archive/2008/09/12/msdn-s-canonical-technique-for-using-control-invoke-is-lame.aspx

Pete