+- Hack Forums (https://hackforums.net)
+-- Forum: Tech (https://hackforums.net/forumdisplay.php?fid=444)
+--- Forum: Coding (https://hackforums.net/forumdisplay.php?fid=151)
+---- Forum: Software Development (https://hackforums.net/forumdisplay.php?fid=118)
+---- Thread: [C#] Easy way to prevent cross thread exceptions with Windows Forms (/showthread.php?tid=5883138)
Pages: Pages
1
2
Easy way to prevent cross thread exceptions with Windows Forms - gigajew - Sep 9, 2018
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
RE: Easy way to prevent cross thread exceptions with Windows Forms - SIM-3991524 - Sep 9, 2018
Honestly my head hurts everytime i see async. I much prefer to just initial Thread, set isBackground to True and Start()
RE: Easy way to prevent cross thread exceptions with Windows Forms - 0xDEAD10CC - Sep 9, 2018
(Sep 9, 2018 07:30 PM)f411en Wrote: 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.
RE: Easy way to prevent cross thread exceptions with Windows Forms - BahNahNah - Sep 9, 2018
I normally just do something like this.
![[Image: wczCaJA.png]](https://i.imgur.com/wczCaJA.png)
RE: Easy way to prevent cross thread exceptions with Windows Forms - SIM-3991524 - Sep 10, 2018
(Sep 9, 2018 07:42 PM)0xDEAD10CC Wrote: 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
RE: Easy way to prevent cross thread exceptions with Windows Forms - 0xDEAD10CC - Sep 10, 2018
(Sep 10, 2018 08:32 AM)f411en Wrote: 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.
RE: Easy way to prevent cross thread exceptions with Windows Forms - SIM-3991524 - Sep 10, 2018
(Sep 10, 2018 08:44 AM)0xDEAD10CC Wrote: 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
(Sep 9, 2018 09:11 PM)BahNahNah Wrote: I normally just do something like this.
bahnanawa did you get RFed?
RE: Easy way to prevent cross thread exceptions with Windows Forms - Nick (Name) - Sep 10, 2018
I still don't get why people are still using WinForms, why not switch to WPF?
(Sep 10, 2018 08:57 AM)f411en Wrote: bahnanawa did you get RFed?
Everyone's reputation got reset.
RE: Easy way to prevent cross thread exceptions with Windows Forms - SIM-3991524 - Sep 10, 2018
(Sep 10, 2018 10:47 AM)Nick (Name) Wrote: 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?
RE: Easy way to prevent cross thread exceptions with Windows Forms - gigajew - Sep 10, 2018
(Sep 9, 2018 09:11 PM)BahNahNah Wrote: I normally just do something like this.
Then you can also just
and save some rows
RE: Easy way to prevent cross thread exceptions with Windows Forms - 0xDEAD10CC - Sep 10, 2018
(Sep 10, 2018 03:15 PM)gigajew Wrote: Then you can also just
and save some rowsCodepublic void InvokeForm(Action a) {
this.Invoke(a);
}
You're missing the point of the InvokeRequired bit there.
RE: Easy way to prevent cross thread exceptions with Windows Forms - gigajew - Sep 10, 2018
(Sep 10, 2018 03:19 PM)0xDEAD10CC Wrote: You're missing the point of the InvokeRequired bit there.
Doesn't matter in this case it'll be invoked either way so
RE: Easy way to prevent cross thread exceptions with Windows Forms - 0xDEAD10CC - Sep 10, 2018
(Sep 10, 2018 04:50 PM)gigajew Wrote: 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.
RE: Easy way to prevent cross thread exceptions with Windows Forms - gigajew - Sep 10, 2018
(Sep 10, 2018 05:19 PM)0xDEAD10CC Wrote: 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
RE: Easy way to prevent cross thread exceptions with Windows Forms - 0xDEAD10CC - Sep 10, 2018
(Sep 10, 2018 05:46 PM)gigajew Wrote: 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/framework/winforms/controls/how-to-make-thread-safe-calls-to-windows-forms-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(...))