|
Excellent.
Try to remember the 'using' construct, whenever you create anything IDisposable. I don't always, particularly when I'm 'just trying something out' and forgetting nearly always causes me problems.
Good Luck!
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
Hi,
I don't understand what it is you are doing here. Either this code runs on the GUI thread, and your Sleep(Infinite) hangs it forever, or it runs on some other thread, and it is not allowed to touch any Controls.
I am afraid your approach is completely wrong.
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
Well, this method doesn't run on the GUI thread but Control.CheckForIllegalCrossThreadCalls is set to false , so all threads are allowed to touch all the Controls.
|
|
|
|
|
SimpleData wrote: so all threads are allowed to touch all the Controls.
That is absolutely false. All CheckForIllegalCrossThreadCalls=false; does is disable the checking (returning to the unhealthy situation that existed in .NET 1.0/1.1), it does not ALLOW anything. Controls are not thread-safe and should be touched only by the thread that created them, and since all Controls are linked somehow (through Control collections, Form Z-Order, etc) that basically means the initial/main/GUI thread is the only one that can touch them. Violating this rule may and will result in abnormal app behavior, typically the GUI freezing pretty soon (or after a possibly long while, but failure is guaranteed).
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
That's good to know, I didn't know that.
I will test my application's stability, maybe it won't be a problem.
|
|
|
|
|
It may pass your tests, but when released into the real world, your code WILL fail. It's just a matter of time before someone out there find the combination of circumstances that will make it happen.
|
|
|
|
|
Just because the property is there doesn't mean it should be used.
I concur with Luc, your approach is completely wrong and unsupportable. I really can't suggest a replacement because it isn't clear what you're trying to accomplish.
Also, when you show a form with ShowDialog, you are responsible for calling Dispose on it to free up unmanaged resources before the object goes out of focus and is destroyed. As it stands now, your code leaks system resources, specifically, window handles. Your code, if left running long enough, will eventually crash Windows.
|
|
|
|
|
What can I do to prevent this?
|
|
|
|
|
Again, we can't really tell you al alternate method without knowing what you're trying to do with this code.
|
|
|
|
|
I am coding an AntiCheat application which takes screenshots of the game and uploads to the server after the games is closed.
When the app is launched, first the login form appears, if the login info is correct, login from closes and mainform that we are talking about appears. App waits for the user to open a supported game. When it's opened it takes screenshots in random intervals. After the game is closed app uploads the taken screenshots.
After uploading them in order to start waiting for a new game to open, I close the mainform and recreate it. This recreation process is what we are talking about.
|
|
|
|
|
Why can't you hide the form, instead of close and reopen?
Regards: Didi
|
|
|
|
|
Because I don't want to keep an extra copy of that form at the back and I need another copy of it.
|
|
|
|
|
Why?? If your code is written correctly, you shouldn't have to do this at all. The code should just fall back to waiting for a suported game to launch.
|
|
|
|
|
I will try to make it work that way.
Thanks.
|
|
|
|
|
I noticed the Thread.Sleep after the this.Close(), but as I could not even start to imagine what was, or was supposed to happen. I therefore very deliberately refrained from mentioning it.
Now you have gone and stirred the whole thing up again!
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
Henry Minute wrote: Now you have gone and stirred the whole thing up again!
Yeah, that's me. Always fighting against those silly Thread.Sleep(Timeout.Infinite); statements which waste an entire stack without achieving anything.
Sorry for being a tad more radical; "Try commenting it out and see if everything still works..." is not really my style.
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
NP
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
I know that that command should not be there but it was a temporary solution and it was working in a way.
This shows that this.Close(); doesn't work. I still couldn't figure out why, if it could then there would be no problem.
|
|
|
|
|
It doesn't close because the ShowDialog method blocks the current thread. It means that the rest of the RestartAll method body is executed after a fresh copy of your mainwindow is closed. Switch to Show() instead. I think that you can also move this.Close above _mainwindow.Show() .
Greetings - Jacek Gajek
|
|
|
|
|
If I do it that way, then no new mainwindow appears.
|
|
|
|
|
please give me a sample codes for Handwritten character recognition in c#,becose i had not idea to implement neural network part,can give me the ideas about neural network layers, which layers can i use for that.
|
|
|
|
|
You seem to have decided that a neural network might help you resolve your problem, but you do not understand neural networks. Well the best way to understand new programming techniques is to try them out. Start with something simple, related to your problem domain, and gradually increase the complexity, until you have solved the problem or run out of talent.
The important thing is to try different things to get an understanding.
We therefore come back to that age old question. What have you tried? I would guess that you haven't tried Google.
You might loke to take a look at Designing And Implementing A Neural Network Library For Handwriting Detection, Image Analysis etc.- The BrainNet Library - Full Code, Simplified Theory, Full Illustration, And Examples[^].
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
Hi, when we click a link(which opens a PDF file) in IE, the PDF file is opened in adobe reader or in IE(if "Display in Browser" is enabled). If the PDF is opened in adobe reader, how can I cancel that, I mean the adobe reader should not be open that file.
How can I do this in c#?
|
|
|
|
|
Generally speaking, you can't.
This is a setting in the browser that the user has control over. The user chooses what should happen when a PDF file is opened.
If you get the user to run an application on the client computer, it would be possible to change this setting, but that is nothing that you would normally do, and nothing that a user would normally allow.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|