Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Do you run into this exception often?
Don't fret; invoke!
If you use winforms often, you may see this exception while trying to change properties of your controls.
For example, I have my "Connect!" button change to "Disconnect" whenever the bot is connected to a world, that way the user knows that they are now connected, and can disconnect by pressing the button again.
However, when I do this, an exception would be thrown because the control I tried to access "crossed" threads. In other words, it's a no-no.
Some people, when they see this exception, try to take the easy way out and change the bool for checking for these illegal operations.
CheckForIllegalCrossThreadCalls = false;
However, this is VERY dangerous. When multithreading, you are basically telling your program to ignore anything wrong rather than fixing the problem. This could cause bot crashes!
There IS a better solution!
Use invocation!
Basically, when you invoke, you're telling your program to search further into your control, until it reaches a parent that it can safely handle.
Here's how to use it!
Instead of
connect.Text = "Disconnect";
I would simply use:
this.Invoke((MethodInvoker)delegate { connect.Text = "Disconnect"; });
And the exception will no longer be thrown, and the code is safely handled.
Always do this next time you are working with controls!
(If there is anything wrong with this method, please let me know.)
Last edited by BuzzerBee (Jun 18 2014 1:20:04 pm)
Offline
I personally used a custom class derived from INotifyPropertyChanged with bindings
I can give more details if anyone wants =P
Last edited by tikenalpha (Jun 18 2014 2:25:37 pm)
Offline
You could also extend this into a handy extension method, there are many ways but this is my favorite:
public static void Invoke<T>(this T control, Action<T> action) where T : Control { if (control.InvokeRequired) control.TopLevelControl.Invoke(action); else action(control); }
Which you can simply use with:
connect.Invoke(c => c.Text = "Disconnect");
Last edited by Cyral (Jun 30 2014 8:36:16 am)
Player Since 2011. I used to make bots and stuff.
Offline
It's quite stupid to invoke one line of code, the same way it's stupid to put try/catch on everything.
Otherwise, it might be useful to implement, but not in ALL cases.
Last edited by XxAtillaxX (Jun 30 2014 5:14:14 pm)
*u stinky*
Offline
However, this is VERY dangerous. When multithreading, you are basically telling your program to ignore anything wrong rather than fixing the problem. This could cause bot crashes!
This is why It's dangerous.
thanks zoey aaaaaaaaaaaand thanks latif for the avatar
Offline
A variable can be written to by 2 seperate threads. I think that's the most common problem (at least was for me).
Offline
I seem to recall that the shortest code required to complete a task is the best, unless it proves to be harmful in some way.
Using "CheckForIllegalCrossThreadCalls = false;" and screwing with threads hasn't done anything harmful to me in 3 years of coding, so there's no incentive to invoke that extra effort (ha).
Let's not make the bot motto: "Per aspera ad astra".
You're also much too vague on why and in which situations it's "very dangerous".
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
I was not vague. I just didn't give copious examples.
The main problem is it can cause crashes. That should be a good enough reason alone not to use it.
Here's a stackoverflow answer as to why it can be harmful:
Offline
checkforillegalcrossthreadcalls is useless when it is stand-alone and it only works for debugging and invoking is 2903293x more better because it removes the random crashiness
I'm getting an exception of crossthread on "form1" not controls and my options are Ok or quit. how to solve.
I'm also getting exceptions on accessing disposed objects by using your invoke method when my app closes
Sample Text.
Doritos/Mountain Dew eater.
420 No scoping 69 scrubs per day
Always smoke weed everyday.
Known for: #getrekt Bot (possible revive with new stuff?)
Offline
My bot uses CheckForIllegalCrossThreadCells = false and it never crashes outside the debugger.
everyone downloading the .exe doesn't crash...
You know what crashes? Missing references.
Offline
checkforillegalcrossthreadcalls is useless when it is stand-alone and it only works for debugging and invoking is 2903293x more better because it removes the random crashiness
I'm getting an exception of crossthread on "form1" not controls and my options are Ok or quit. how to solve.
I'm also getting exceptions on accessing disposed objects by using your invoke method when my app closes
use CheckForIllegalCrossThreadCells = false;
Remove all the useless invokes. (Why the **** do people even spam it on the bot)
'Random crashinies' Then or missing references or ur code is wrong
'Only on debug' my bot is working on Release and the official .exe
Dude, seriously, debug it from a file with cloned references, not in project directory...
Offline
darkblades wrote:checkforillegalcrossthreadcalls is useless when it is stand-alone and it only works for debugging and invoking is 2903293x more better because it removes the random crashiness
I'm getting an exception of crossthread on "form1" not controls and my options are Ok or quit. how to solve.
I'm also getting exceptions on accessing disposed objects by using your invoke method when my app closes
use CheckForIllegalCrossThreadCells = false;
Remove all the useless invokes. (Why the **** do people even spam it on the bot)
'Random crashinies' Then or missing references or ur code is wrong
'Only on debug' my bot is working on Release and the official .exeDude, seriously, debug it from a file with cloned references, not in project directory...
Personally crashes thanks to this.
My bot has a little loop going on in one of the threats, by using your 'oh-so-much-better' method, this causes the bot to crash occasionally because a single variable is being accessed by two separate threads at the same time.
Using the better, safer way (personally use a bit different method that Bee does, but it's not a pretty one-liner), I don't have that problem anymore.
You bot might too crash because of this, but since I had a loop going on, the chances of it happening on me were a lot bigger.
Offline
marcoantonimsantos, please don't argue about this. You are wrong. Goodbye.
Offline
marcoantonimsantos wrote:darkblades wrote:checkforillegalcrossthreadcalls is useless when it is stand-alone and it only works for debugging and invoking is 2903293x more better because it removes the random crashiness
I'm getting an exception of crossthread on "form1" not controls and my options are Ok or quit. how to solve.
I'm also getting exceptions on accessing disposed objects by using your invoke method when my app closes
use CheckForIllegalCrossThreadCells = false;
Remove all the useless invokes. (Why the **** do people even spam it on the bot)
'Random crashinies' Then or missing references or ur code is wrong
'Only on debug' my bot is working on Release and the official .exeDude, seriously, debug it from a file with cloned references, not in project directory...
Personally crashes thanks to this.
My bot has a little loop going on in one of the threats, by using your 'oh-so-much-better' method, this causes the bot to crash occasionally because a single variable is being accessed by two separate threads at the same time.Using the better, safer way (personally use a bit different method that Bee does, but it's not a pretty one-liner), I don't have that problem anymore.
You bot might too crash because of this, but since I had a loop going on, the chances of it happening on me were a lot bigger.
are you using Thread.Sleep? Those are important in Loops.
Offline
are you using Thread.Sleep? Those are important in Loops.
Wait... what?! If you are relying on Thread.Sleep to save you from a crash, you're in deep troubles my friend.
Offline
marcosantonimsantos wrote:are you using Thread.Sleep? Those are important in Loops.
Wait... what?! If you are relying on Thread.Sleep to save you from a crash, you're in deep troubles my friend.
Actually, I'm talking about loops.
Not using Delay or Thread.Sleep in those will give StackOverFlow, crashing his bot, and here is where he is doing it wrong...
Offline
TiKen wrote:marcosantonimsantos wrote:are you using Thread.Sleep? Those are important in Loops.
Wait... what?! If you are relying on Thread.Sleep to save you from a crash, you're in deep troubles my friend.
Actually, I'm talking about loops.
Not using Delay or Thread.Sleep in those will give StackOverFlow, crashing his bot, and here is where he is doing it wrong...
Illegal cross thread calls and stack overflows are two completely separated things (even if the second can result from the first one) O-o
A stack overflow has no reason to show up in ANY loop if boundaries are well set. The only reason I see here to a stack overflow showing in your loops is if a thread changes the size of an array/list while another one is using it (I made the hypothesis you know how to define boundaries to avoid a basic stack overflow).
tl;dr: You just prove yourself wrong. DO NO CREATE ILLEGAL CROSS THREAD CALLS
Edit: Stack overflows can also happen in recursive functions where boundaries are ill-set, or if there is simply to many calls. But I don't think it's what is showing up here.
Offline
▼someqoutesare you using Thread.Sleep? Those are important in Loops.
I am using some form of delay for the loop, yes, but the problem is, that a quick loop has a higher chance to get a variable to be accessed from 2 separate threads is much higher than when using one-time operations.
Yet still, just like in your bot, it's perfectly possible that it will still happen and your bot will crash.
And people won't be happy to hear it's something you can't/won't fix, gives you bad cred.
Offline
Just because your bot doesn't crash, doesn't mean it won't.
thanks zoey aaaaaaaaaaaand thanks latif for the avatar
Offline
marcoantonimsantos wrote:▼someqoutesare you using Thread.Sleep? Those are important in Loops.
I am using some form of delay for the loop, yes, but the problem is, that a quick loop has a higher chance to get a variable to be accessed from 2 separate threads is much higher than when using one-time operations.
Yet still, just like in your bot, it's perfectly possible that it will still happen and your bot will crash.
And people won't be happy to hear it's something you can't/won't fix, gives you bad cred.
Try using timers
Offline
▼someqoutesTry using timers
As I said, I'm already using some form of delay... And as I also said, the delay isn't causing the crashes... Just nvm...
Offline
So far I have just kept creating backgroundWorkers with events in lambda expression. It's quite easy and readable.
shh i have returned
Offline
[ Started around 1732481633.4448 - Generated in 0.117 seconds, 12 queries executed - Memory usage: 1.86 MiB (Peak: 2.16 MiB) ]