Wow! You have such a myopic view of what's going on.
I don't think so. Let's revisit this one more time.
So I'm supposed to put all code that modifies a control into wrapper code that calls invoke and this wrapper code ends up being a conditional test to see if invoke is required and then recursively calling the same function thru a special delegate that is created just for that invoke call. I've repeated my example code below:
private delegate void RefreshLbxDg8();
private RefreshLbxDg8 _refreshLbx;
_refreshLbx = RefreshLbx;
public void RefreshLbx()
lbxQuotes.DataSource = null;
lbxQuotes.DataSource = _quotes;
All this is required in order that the code gets executed on the GUI thread. Now, I'm simply updating a textbox with a sample (number). Nothing else.
I guess I could have stated my point better: yes, it is an asynchronous system and it is *possible* that a WM_PAINT would get processed while the textbox text is changing. I am aware of this. My complaint was that .NET designers used this sledgehammer solution to prevent any presentation rendering mishap (ie. my number is rendered while it is changing) by constraining all code to execute on the GUI thread. So this means that for every single interaction with any control - and there's a LOT of them, I'm supposed to write wrapper code around everything, and this wrapper code involves defining and creating delegates and rewriting all my code to include a conditional statement which tests for this invokability.
AND YOU'RE FINE WITH THIS.
Me, I think this is a horrible and terribly primitive solution and design. It would be better to leave me with using SendMessage() to inject my action into the GUI's Message-Loop.
And that's not to mention that the compiler gave no warnings, there was no runtime error, the code SILENTLY failed, and I had no idea that the timer implemented its actions with a (hidden) separate thread.
I am LESS than impressed.