I am learning to program in C# for .Net using VS2015 Community Ed.
Its my first question so if I am not in the correct format I apologize.
At present I am trying to click a button and have the program begin a countdown. This countdown item should be named (ie..Timer1) and its name appear in a ComboBox. That part is the easy part. The part where I am having an issue is figuring out how to have the timer continue if the program is terminated.
Is there a way to keep the countdown running after program termination until specifically terminated by the user? If so, What should I be searching for in order to learn this?
You could hide your form but the timer still continue, but there is no space for the timer to run if you close the application. It has to live in an application. I think what you're probably looking for is it living longer than your form, that is possible, just move the timer's scope up higher than the form, you'll have to play with the Program class, maybe make the form modeless instead of modal, or maybe not. You'll have to try a few ways. But the timer will have to run in your application, everything in your application dies when the application does.
The only way to have your timer continue to run after your process exits is to launch a separate process in which the timer will run. Of course, the original process will no longer have access to the timer, so you'll need to use some form of interprocess communication to allow the timer process to inform the original process of the timer state.
Related
I am having one windows forms application which is designed to do specific tasks in background. Now I want to make sure that this application should be running all the time.
No one should able to close it. If some one closed it from Task Manager (Kill it) then it should restart it self.
I had couple of options for that. I have tried to make one window service which has timer and which can be check at every 1 minute that if process is not found then it will launch the process. But I have gone through couple of articles and they are saying that this is not nice idea. Is there any other way round to keeping alive my application in windows.
In my idea also if someone closes my service then also I can't detect if my WinForms application is closed or running.
What is best way to do so? I am ready to give highest privileges and I have thought that option as well that If someone kill process of my application then computer should be shut down it self.
Please share better idea to do so.
If you don't want the user closing your app, make it as difficult for him as possible:
launch it maximized
remove the frame of the window (and close, maximize,minimize buttons with it)
launch it TopMost
set ShowInTaskbar of your forms to false
ask 10 times "are you sure you want to exit???" :)
set e.Cancel to true in FormClosing event, etc...
About the Task Manager:
I think you can disable task manager altogether http://www.techulator.com/resources/3480-how-disable-task-manager-windows.aspx
Or you can hide the process (ugly and virus-like): How do I hide a process in Task Manager in C#?
Or you can sort-of make it harder to kill the process: Making an app/service such that trying to end/kill its process in Task Manager would result in "Unable to Terminate Process"
Then, if the user still manages to close your app, you can do what most people on the Internet consider a Very Bad Idea and start it from the service. As long as you are concious of the risks.
There are plenty of resource out there that tell you how to start an interactive app from the service (so evidently some people are doing it too), for example:
http://blogs.msdn.com/b/winsdk/archive/2009/07/14/launching-an-interactive-process-from-windows-service-in-windows-vista-and-later.aspx
you should know that it is impossible to prevent task manager not to close your application. and its not a proper idea to force the user.
But, if you insist I think the best way is through services with timer or thread whichever suits your solution to check its process and run it if not exists. and you didn't mention in your post that what was the reason of not using this method and why it is not a good method.
hope it helps you decide better.
I am making a game wumpus world in winforms in which an agent(computer) can move in 4 directions. I am using button control for base and showing and hiding images where ever needed. i used Thread.Sleep for that but problem is that when i click button nothing is showing on form. the process on background is working fine but it is not showing each step. and yes i am using Thread.Sleep in current UI Thread.
I want to show every step to users with interval of 2 seconds.
it's hard to answer without any code to go by, but the main problem as i understand it is that you change the look of the world, and then tell it to sleep, witch means nothing will be painted. and then when the thread wakes up, you again change the world and make it sleep. nothing will be painted that way.
better way to do it will be timer, make it a single timer and a queue of events that needed to be shown and you are on your way to do it.
are you working on winForms, because if you are working on WPF you can do much nicer things
Edit: I'm not saying that Timer is the best way to do it, but it's a good valid way
Using Thread.Sleep is a poor design choice for several reasons:
It blocks the thread for the duration of the time it is sleeping.
It uses up threads in the thread pool, so this solution will not scale well at all.
It is a bad timing mechanism, because there is a time slice, or quantum, in play here that varies between operating systems and even versions of the same operating system (read: Windows).
This previous SO question gives more information about why Thread.Sleep is bad:
Why Is Thread.Sleep So Harmful
i have the following problem. When the user closes the Windows store app, i want a text file with data to be saved.
What method should i write so that when closing the app a file gets saved ?
This article describes the application lifecycle of a Windows Store App.
If you look at the very first figure, you can see that there are only 3 events related to application lifecycle:
Activated - Raised when program first starts
Suspended - Raised when program is suspended (i.e. the user returns to the Start Screen or another app)
Resuming - Raised when the program is awakened from its suspended state.
The fourth transition - the one to the "Not Running" state - has no such notification event. The reason is: you don't really know when the app will fully close. Nor should you - Microsoft wants you to perform all of your state-saving logic in the transition from "Running" to "Suspended." In this way, they can free up resources when they deem necessary.
Even if the user forces the program to terminate (by right-clicking it and selecting "Close" from the task menu), you will enter the "Suspended" state for exactly 10 seconds before the program is terminated. So you can rest easy that your state-saving logic will always be executed.
you don't really know when the app will fully close. Nor should you...
I don't agree with this - Microsoft are copying this from Apple, and I don't know why, I never liked Apple's implementation either.
If your user makes changes to your App, then closes it using the keyboard or gesture, then restarts it say after 6 seconds, all changes are lost.
I don't see any way as a developer to get around this. Whoever decided that closed events (and exit buttons for that matter) are evil is an idiot.
I made a program based on Aforge (it's a video library). This library creates its own refresh events for the next video frame from camera. So far so good, earlier people have helped me with multi threading so these Aforge threads could report back to the main program thread, again so far so good, it works great.
The code can be seen here: how to do multithreading when using outside referenced code.
But now I regularly notice a new program error. The problem starts when I want to exit the program. At the moment the Aforge thread might still be active. And it wants to write back to main form that is closed.
Somehow I need to stop the other thread before I close the program. There is an option in Aforge to do something like camera stop, but it's not enough. But then still my code wants to write on the main form that's already closing.
Is there a way to stop all threads, or some safe way to close from the originating thread? I even placed the back reporting to the main program in a try catch construction but it didn't work well, the only way of stopping it in these situations is to press the stop execution button within Visual Studio itself.
If I understand your problem correctly, you may have an Invoke call about to happen on your form just as you've closed the form. I've had this happen as well.
What I've done is to set a "shutdown" variable when I start to close the form, and then use AppDomain.CurrentDomain.UnhandledException to watch for InvalidOperationException (or whatever you're getting), and ignore if shutdown is set.
I'm working on a console app that kicks off a fairly long running process (2-3 minutes). What options are available for displaying progress, or even just writing a "." to screen every few seconds so the user knows the app hasn't stopped responding?
You have (at least) 3 ways to do this:
Simplest: On program start, set a global variable to false, then start a thread that writes a dot to the console, Thread.Sleep()s a second, repeats until the variable is set to true. On your main thread do your work, when finished set the variable to true and then Join() the other thread.
Still simple: Add another global variable to the mix, type int. In your worker thread increase it, whenever some progress is made, on the console writer thread reduce interval to say 250ms, but draw a dot only if progress counter has changed. This gives an idea of how fast your app progresses
A bit advanced: Create a boolean as in first step plus an AutoResetEvent, let the console writer thread repeatedly wait on the event, when app makes progress Set() the event. When finished set boolean to true and Set() again before Join()ing. The advanced part in this is to know, in what portions to report progress.
The simplest approach is if your application has an incremental loop then you could put a simple full stop on the the console. Not nice, but it does give an indication of "I'm alive".
But that approach can result in too much info (too many characters going to console) or too few as your hooking into a bit of the code that does not really have that responsibility.
So, perhaps a nicer way that you can reuse is to create a console user class that is run in a thread with a 1 second tick. It can use backspacing and the good old | / | / - sequence to give the impression of something rotating. It can also check for key presses to allow the user to exit.
Another option, depending on the nature of your users, is to use a logging framework like NLog. That way your implementation is UI independent and you can see what is happening in more or less detail at run time in the console, from another machine, whatever.