[gigajew]

This is my code to prevent cross thread exceptions when (for example) setting the text of a textbox from another thread

Here's the code. You only need this one snippet instead of all kinds of delegates and crap.


This is some sample usage

[SIM-3991524]

Honestly my head hurts everytime i see async. I much prefer to just initial Thread, set isBackground to True and Start()

[0xDEAD10CC]

Honestly my head hurts everytime i see async. I much prefer to just initial Thread, set isBackground to True and Start()

Except that doesn't do the same thing at all as async/await.

As for the example, it doesn't make sense, but even if you wanted to use something similar to this, I wouldn't ever lock in an async method like that. That's potential for inadvertent deadlocks in my opinion.

[BahNahNah]

I normally just do something like this.

[SIM-3991524]

Except that doesn't do the same thing at all as async/await.

As for the example, it doesn't make sense, but even if you wanted to use something similar to this, I wouldn't ever lock in an async method like that. That's potential for inadvertent deadlocks in my opinion.

hey dead, ik your into native winapi alot too. If this were native C/C++ would you use CreateThread? Obviously you will be more efficient with asynchronous call, but I think there's always a multithreaded solution that feels... cleaner

[0xDEAD10CC]

hey dead, ik your into native winapi alot too. If this were native C/C++ would you use CreateThread? Obviously you will be more efficient with asynchronous call, but I think there's always a multithreaded solution that feels... cleaner

It depends on what you're doing, sometimes it doesn't make sense to use a thread because you need to join the thread anyways along with potential thread context switching causing the overall flow of execution to be worse for performance than if you were to just do things on the same thread. Ex: updating a single label on a thread to display 1 .. 100; you would need to halt threads that would display higher numbers until the lower numbers have been displayed on the label, it needs to happen sequentially anyways, and this isn't quantum mechanics, so it can't be 1..100 all at the same time either. If you spawned ~100 threads for each, you would probably see worse performance from having threads wait to be resumed at a later time.

[SIM-3991524]

It depends on what you're doing, sometimes it doesn't make sense to use a thread because you need to join the thread anyways along with potential thread context switching causing the overall flow of execution to be worse for performance than if you were to just do things on the same thread. Ex: updating a single label on a thread to display 1 .. 100; you would need to halt threads that would display higher numbers until the lower numbers have been displayed on the label, it needs to happen sequentially anyways, and this isn't quantum mechanics, so it can't be 1..100 all at the same time either. If you spawned ~100 threads for each, you would probably see worse performance from having threads wait to be resumed at a later time.

Agreed agreed, obviously the convention exist for a reason. Ive also noticed my .net apps having a stupid high number of threads. Have you seen that at all? Ive had times where just the default winForm project had like 4 threads lol. Dont remember exact numbers

---

I normally just do something like this.

bahnanawa did you get RFed?

[Nick (Name)]

I still don't get why people are still using WinForms, why not switch to WPF?

bahnanawa did you get RFed?

Everyone's reputation got reset.

[SIM-3991524]

I still don't get why people are still using WinForms, why not switch to WPF?


Everyone's reputation got reset.

I use winForms because its what i know and i can make UI's quickly in it. WPF is newer by all means

And wtf? when did that happen?

[gigajew]

I normally just do something like this.

Then you can also just


and save some rows

[0xDEAD10CC]

Then you can also just

Code

public void InvokeForm(Action a) {
  this.Invoke(a);
}

and save some rows

You're missing the point of the InvokeRequired bit there.

[gigajew]

You're missing the point of the InvokeRequired bit there.

Doesn't matter in this case it'll be invoked either way so

[0xDEAD10CC]

Doesn't matter in this case it'll be invoked either way so

You're assuming the use case where someone is always using threads. That does not mean that the code you suggested as an alternative does the same as what he had, and I wouldn't suggest it just to "save lines of code" either.

[gigajew]

You're assuming the use case where someone is always using threads. That does not mean that the code you suggested as an alternative does the same as what he had, and I wouldn't suggest it just to "save lines of code" either.

No you can use without threads too that's the whole point of the one liner instead of the if checks

[0xDEAD10CC]

No you can use without threads too that's the whole point of the one liner instead of the if checks

I know you can but what I was saying is that the code is not the same as your one-liner solution, and the fact that you don't really understand what is going on there. You're still one of those people that thinks LINQ is better because it allows you to write lots of one-liner code I presume too? ... ❓

I don't know why you're suggesting a one-liner in his case either anyways, because if you applied that same logic to your example, all you'd have left is this:

Code

await Task.Factory.FromAsync(
                    control.BeginInvoke(modifier, control),
                    control.EndInvoke
                );

I'd advise you to read these:

https://stackoverflow.com/a/22409146
https://stackoverflow.com/a/12179408
https://docs.microsoft.com/en-us/dotnet/...s-controls

This is also where people go wrong with this type of setup... They invoke the entire processing back on the UI thread instead of the code that just updates the UI itself which is mainly the reason why you would marshal back to the UI thread in the first place, but then it defeats the point of even doing something on a separate thread. Most people for that reason will look at this and use it incorrectly without understanding what they're doing, and it's not the best generic implementation to begin with either.

Delegate invocation is really the only syntactic sugar that would make such a call identical. (i.e. modifier(...) or modifier.Invoke(...))