Raising UI-level events from a thread without using Invoke?

[Bruce Wood]

I would hope it does. Otherwise, wouldn't the call to Invoke simply
deadlock? That is, on another thread it would wait for the main thread to
process the Invoke, but if the main thread is waiting already (because
it's the thread calling Invoke) it seems to me it would never get a chance
to process the Invoke.

I've always found it a bit odd that all the "classic" Invoke examples
bother to check that Invoke is required.

Most of the "classic" Invoke examples I've seen do this in order to re-
use the same routine as Invoked or not Invoked, viz: the routine
checks InvokeRequired and, if it's true, Invokes "itself", so the
second go around InvokeRequired will be false and the "else" part will
execute the actual machinery of the method.

Of course, if you use two methods: a facade that calls Invoke and
another method that does the actual work, there's no real need to
check InvokeRequired in the first routine.

 

[Thomas Due]

Note, however, that the two methods you've given do different things -
the first only calls Invoke when it needs to, the second always calls
Invoke, even if it's already on the right thread.

Well, that is my main concern with the second method, and why I posted it here.

But, in all regards, I would like to thank you all for your input. I have considered the matter carefully, and decided that I will go with the "tranditional" method, i.e. using InvokeRequired.

All in all, although I think it is a ridiculously huge amount of code necessary to ensure thread safety *in every event handler* it is far easier and quicker to do, than to figure out how to put it in the signaler code, so it is hidden away from the GUI code.

So, although it is damn ugly, it seems to be the lesser evil.

--
Thomas Due
Posted with XanaNews version 1.18.1.6

"Talking much about oneself can also be a means to conceal oneself."
-- Friedrich Nietzsche

 

[Brian Gideon]

But, in all regards, I would like to thank you all for your input. I have considered the matter carefully, and decided that I will go with the "tranditional" method, i.e. using InvokeRequired.

That's fine. I personally prefer the anonymous method implementation
myself. I don't know...it just seems more elegant

 

[Peter Duniho]

Most of the "classic" Invoke examples I've seen do this in order to re-
use the same routine as Invoked or not Invoked, viz: the routine
checks InvokeRequired and, if it's true, Invokes "itself", so the
second go around InvokeRequired will be false and the "else" part will
execute the actual machinery of the method.

That's true. But I don't see the advantage of keeping all the code in a
single routine. Everyone can still call an invoking rotine, and the
invoking routine can use a separate delegate method to do the actual work.

In fact, to my eye having a single method have two entirely different
behaviors goes against my general coding principles. It's not terrible in
this case, but it's not pretty either.

Of course, if you use two methods: a facade that calls Invoke and
another method that does the actual work, there's no real need to
check InvokeRequired in the first routine.

Exactly!

Pete