I am now developing an application on Windows Mobile 6.5 with .Net Compact Framework 3.5 using C#. There is a function in the program that I use it to update the location information periodically from server side, but if I keep running this computation, it would cost too much energe. For this reason, I want to run it in background and I try to use BackgroundWorker to do this and it works well.
The problem I have now is that I can't minimize the program so that I have to keep the main form of the program run in foreground even if it's not doing anything and this is very inconvinence for a user. However, when I close the program, the BackgroundWorker will also be closed.
Is there any method to keep the update process running (somewhere in memory or so) when I close the program? and then can restore the information when I restart the program?
How about creating a Service instead of a background worker?
If your Form closes, then Application.Run (probably called over in Program.Main) returns and the process' primary thread exits, causing the application to terminate.
The solution, then, is don't close the Form, simply Hide it. By default the "MinimizeBox" property for your Form should have been true and it should have an [X] in the upper right corner. Clicking this minimizes the Form and will not exit your application.
The other option in some cases is to not have a Form at all. The challenge here is that the CF doesn't have any Application.Run overload that doesn't accept in a Form (like the desktop framework does). The Smart Device Framework does provide one if you want to go that route.
I have not used the .NETCF 3.5. However in the previous version on .NETCF 1.0/2.0 I observed that even if you close the application using (X) button, it just goes to background but remain in the memory.
If that is the case with .NETCF 3.5 as well then I think you do not need to anything here. The background worked will be running even if you close the application.
I Hope this will help you.
Related
I have a console application that shows latest activities & status on its console. The application is heavily threaded & performance is the major concern. No user interactivity is required. Due to a recent case, ive been asked to migrate it to a win form application.
Initial post ->
How to programmatic disable C# Console Application's Quick Edit mode?
So to encounter the problem, I have used Application.Run(ApplicationContext context) so to start a message loop in my console application so that i can hook and trap mouse events and can reset quick edit mode at runtime. I have also deleted a Console's default menu item "Edit" that emerges on right click so not to allow the user to Mark/Copy/Paste.
I want to know what should be the optimal solution, migrating to win form or console app (considering changes i made). Also i need to call Invoke every time in order to put the task in UI's queue so to print the message if migrated to winform.
WinForms would definitely give you more flexibility in what you can do with the UI.
In terms of performance, you really need to be doing a lot of UI updates in order for performance to be a concern. It sounds like that will not be the case since you're currently getting it done with a console application. Most of the time, the UI performance is affected not because the UI thread can't keep up with the updates, but because non-UI stuff (e.g. file IO, database queries, etc.) is done within the UI thread.
I would consider to change your application so that it streams it's output into a logfile, a lightweight database or a Windows event log instead to the console. Thus your application won't need a console or UI at all and can be alternatively run as a service. If someone wants to see that messages, give him a separate (probably Winforms) program to view the latest output, or if you use the Windows event log, he can just use the Windows Event viewer to check the output of your program.
So you neither have to migrate you application to Winforms, nor do some ugly console hacks.
To process log files, the Microsoft log parser may be of interest for you.
I have an application that imports data from Excel. However, when I run the winforms app and I intrupt the application, using System.Windows.Forms.Application.Exit(); I can still see the "MyAppName".vshost32.exe running in task manager.
When I exit the application in debug mode, the form closes, but the VS IDE is not "stopped".
How do I ensure the application ends correctly.
Your call to Application.Exit() is working fine. The MyAppName.vshost32.exe executable is a host for debugging purposes. It runs whilst you have a project open in Visual Studio, regardless of if there is an active debugging session.
Update: Ok, I misunderstood. The above is true, but you're probably having problems with hung threads in the background. You need to terminate your threads to make it close properly. Asher's answer covers this. If you're just trying to do a super-hacky quick-and-dirty kill, you can use the following (though I take no responsibility for side effects, since it's extremely hacky):
System.Diagnostics.Process.GetCurrentProcess().Kill();
The process doesn't terminate because it still has foreground threads running.
If you create threads in your application you need to mark them as background threads or make sure they terminate when you want the application to exit.
Have you tried the more brutal Environment.Exit() function?
Application.Exit() just sends a message saying to shutdown; if the message never gets processed (for whatever reason), the application will stay running indefinitely.
From the MSDN documentation of Application.Exit():
The Exit method stops all running message loops on all threads and closes all windows of the application. This method does not necessarily force the application to exit. The Exit method is typically called from within a message loop, and forces Run to return.
I had a similar problem caused by a third party tool that did not allow me to set the threads as Background. Polynomial had the right idea, but then syntax is like this:
System.Diagnostics.Process.GetCurrentProcess().Kill();
lets say you are adding a feature to an old and running windows form application now the whole application is running in one thread and the application is really big and have many forms so you cant refract it to run in multithreads, now the application gui freeze everytime you make a process , is there is any way to have an indicator that its loading or in progress while its freezing ? without changing the whole design of the software to support threads etc ?
by the way i dont want it to stop freezing its ok to freeze i just want it to to indicate that its doing something !
any idea would be appreciated, thanks...
See BackGroundWorker componet if application is written using .net 2.0 or higher version.
You can set the form's Cursor property to Cursors.WaitCursor upon starting the long running action, and reset it to Cursors.Default upon finish. While your action executes you can call Application.DoEvents() but it may cause side effects if other events trigger in the mean time.
I have a C# windows application. I placed it on a test server, whose set up is not controlled by my company and neither is the seurity context. I double click the exe. App runs and i see my form. I close the application, i open task manager and i still see a foot print of the applicatiion.
taskkill does not seem to remove it and it is still running in task manager.
how do i check if any resource is still being held?
The likely cause is that a background thread is still running after your application is closed. Depending on your framework and application configuration a background thread can cause a process to keep running even after the main window is closed.
Do you have any threads in your process? If so make sure to close them out when the main application window is closing. A good place to do this is in the OnClosing method of a Windows Form
Abusing Application.DoEvents() is another way to get into this kind of trouble. If you cannot kill the .exe from TaskMgr, your app is stuck waiting for a driver to finish an I/O request.
What is the best and cleanest way to close a console application on windows mobile?
The application by default is invisible and you cannot see it in the running programs, which is great for running a background process, but sometimes the user might need to close it..
Exit Main. Seriously. If you need someone to be able to exit is manually, there needs to be some mechanism like a shell icon and menu or a program in the Programs folder of something. How else would the user even know it's running? Any one of those visual cues would then set a named system event, and inside your Console app you'd have something listening for the same event (likely a worker). When it gets set, you take the actions required to shut down.
How would a user be able to close it if the application is not visible in the UI?
That's a great question. I once spent a long time trying to figure this out. Of course, we are assuming you can not (easily) return from Main. The correct answer on the desktop is System.Environment.Exit; But that method is conveniently not supported on CF.
An apparent second option is Application.Exit. That is on CF, but only applies to WinForms, and is in fact not guaranteed to exit your application.
So, throw an unhandled exception. ;)
EDIT: To kill it programatically from another app, you can look at Process.GetProcessById, and Process.Kill. Both of these are available on CF. You will have to somehow let the "killer" app figure out the "victim"'s ID. More convenient methods like Process.GetProcessesByName are not available on CF.
This technique isn't that elegant, though, and there may be permissions issues.
You could also consider some kind of IPC (inter-process communication), perhaps one overviewed in this previous Windows Mobile answer.
I decided to to read a boolean (keep alive) in the config file and have another application set it to false when I want to exit.
Its not that responsive but at least I can exit cleanly..