|
if (result != Common.ErrorMsg.ErrorNone)
{
this.Dispatcher.BeginInvoke((ThreadStart)delegate()
{
});
return;
} I found this in code that is guaranteed to be called on the dispatcher's thread. Sigh2.
Software Zen: delete this;
|
|
|
|
|
Someone probably planned on coming back and filling this in someday.
|
|
|
|
|
That explains why he copy/pasted it all over the place.
Software Zen: delete this;
|
|
|
|
|
I guess he liked spaghetti (code) with a side of Copy-Pasta.
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
Procedural Object Oriented Programming (POOP).
|
|
|
|
|
Another guy here has his Special High-Interest Task list.
Software Zen: delete this;
|
|
|
|
|
Given you said it was replicated in multiple places, I can see only one possible perceived value -- to block this function from returning until after the dispatcher thread is finished executing something else. Such behavior isn't guaranteed, but it would work just often enough that I can easily see someone clueless thinking it does. Before totally writing it off, I'd look carefully at what's done with the dispatcher prior to executing this code.
As pointed out, this only makes sense if its run with an Invoke , instead of the BeginInvoke that's being used. Nevermind
We can program with only 1's, but if all you've got are zeros, you've got nothing.
modified 2-Apr-13 14:09pm.
|
|
|
|
|
It's a BeginInvoke call, which only blocks (very) briefly while the work item is queued to the dispatcher. The dispatcher in turn will execute a brief delay at some point executing the 'empty' work item.
Software Zen: delete this;
|
|
|
|
|
D'Oh! I wasn't paying attention and thought it was an Invoke call. Yeah, BeginInvoke has absolutely no value
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Aaaahhh!, nothing like a do nothing instruction early in the morning...
|
|
|
|
|
I forget exactly what the purpose was, but I've seen something very similar done in WPF. The purpose was something like forcing the rendering to refresh. Though, I thought some "priority" (or something like that) was necessary for it to work.
I know, vague, but there could be a real purpose (that they apparently didn't leave a comment for).
|
|
|
|
|
WPF has the same constraint that you had under Win32 and MFC: you can only modify UI objects from the UI thread. I think the intent here was to promoted a UI change to the UI thread. Unfortunately, this code appeared in handlers that are already guaranteed to be called from the UI thread.
Software Zen: delete this;
|
|
|
|
|
That's a pretty special no-op.
As for using Invoke/BeginInvoke though, unless it's really really obvious that it can only be called in the dispatch thread (e.g. it's in an event handler or something), perhaps it used to be used from multiple threads, or the author couldn't be sure?
|
|
|
|
|
BobJanova wrote: it can only be called in the dispatch thread (e.g. it's in an event handler Got it in one. I explained this fact to the guy a number of times, and it still didn't seem to sink in.
Software Zen: delete this;
|
|
|
|