I would like to have my current application close and restart. I have seen many posts on this, however none of these seem to work for me.
I have tried
System.Diagnostics.Process.Start(System.Windows.Application.ResourceAssembly.Location);
System.Windows.Application.Current.Shutdown();
However this only restarts the application once. If I press my 'restart' button again (on the already restarted app), it only closes.
I have also tried launching a new System.Diagnostics.Process and closing the current process, but again this does not restart, it simply closes.
How can I restart my current WPF application?
You could create another application which you start when exiting your app and which in return does start your application again. Kind of like how a patcher would work, only without patching anything. On the plus side you could have a loop in that "restart-application" which checks all running processes for your main application process and only tries to re-start it once it does not appear in the process any longer - and you got the bare bones for a patcher also :) Whilst you do not seem to have a problem with restarting your application due to it still being in the processlist - it is the way I would go for when doing it in a production environment as this gives you the most control IMHO.
Edit:
That part in the button event handler (or wherever you want to restart your app with) of your main app (Process2BRestarted.exe in my case):
private void cmdRestart_Click(object sender, EventArgs e)
{
var info = new ProcessStartInfo();
info.FileName = "ProcessReStarter";
info.WindowStyle = ProcessWindowStyle.Hidden;
Process.Start(info);
Application.Exit();
}
This should go into your utility/restarter application (ProcessReStarter.exe over here):
private void MainForm_Load(object sender, EventArgs e)
{
// wait for main application process to end
// really should implement some kind of error-checking/timer here also
while (Process.GetProcessesByName("Process2BRestarted").Count() > 0) { }
// ok, process should not be running any longer, restart it
Process.Start("Process2BRestarted");
// and exit the utility app
Application.Exit();
}
Clicking the restart button will now create a new process ProcessReStarter.exe, which will iterate through the process list of all running processes - checking whether Process2BRestarted is still running. If the process does not appear in the list (any longer) it will now start a new Process2BRestarted.exe process and exit itself.
Related
I have a game running in XNA.
In order to create the menus and dialogs I am using windows forms.
My main issue - however, is with my 'Game Over' dialog.
When you die, a message appears asking if you want to try again. When you do - it opens up another instance of xna (so you have two running).
When you select 'Try Again' I would like the first to close and to open a second one.
XNA Game1.cs
GameOver gameover = new GameOver(level, levelManager, kills);
gameover.ShowDialog();
this.Exit();
'GameOver' is the name of the windows form that displays the game over stats.
(This takes the level that the user is on and starts the game at that level)
GameOver.cs (Windows form)
private void button1_Click(object sender, EventArgs e)
{
Visible = false;
Thread thread = new Thread(() =>
{
Game1 game = new Game1(level);
game.Run();
});
thread.Start();
thread.Join();
}
Any help is much appreciated.
i'll sum up the whole thing:
You need to write a reset method that will reset the game window. you can do it by taking all the code in the contractor and put them in another method and call that method in the constructor and in the reset method. make sure you don't leave anything off the reset. any member or connection that need to be initialized.
you can also open a new window and close the current one, but that's not the right way of doing things
There is a Win app tool(C#) running at terminal server which is used to download mails, process the attachment in it and update its UI. Downloading and processing of mail attachments is done using the Background Worker process which also responsible for updating the UI with mails and attachments total and processed count at that instance. There is a timer which ticks to re-initializes the same background worker process after specified duration and look for new mails.
All works fine till the time I am logged in RDC, but when I lock the system (Window key+L) or switch users and comeback to regain the same session the tool is stuck/non responsive, it happens even if I lock and unlock the system instantaneously. I used another process monitoring tool which initially showed child threads getting created and exited periodically but after it is stuck no activity is shown.
I have no clue why is it happening, is window messing is stopped or UI Controls handle are lost or or or....
Following are the chunks of code I am using:
private void tmrScheduler_Tick(object sender, EventArgs e)
{
Application.DoEvents();
if (bgwMailParser == null || (!bgwMailParser.IsBusy && !objfeMailImportNParse.Is_Parsing))
{
bgwMailParser = new BackgroundWorker();
bgwMailParser.DoWork += new DoWorkEventHandler(objfeMailImportNParse.opLoadCommonData);
bgwMailParser.DoWork += new DoWorkEventHandler(objfeMailImportNParse.StartMailImport);
if (HireCraft.Properties.Settings.Default.Close_App_After_Parsing)
bgwMailParser.RunWorkerCompleted += new RunWorkerCompletedEventHandler(opCloseApplication);
bgwMailParser.RunWorkerCompleted += new RunWorkerCompletedEventHandler(opDisposeWorker);
bgwMailParser.RunWorkerAsync();
}
Application.DoEvents();
}
below method handles the events raised by bgWorker process
private delegate void Del_updateParsedCounter(Int64 del_MailCount, Int64 del_AttchCount);
private void UpdateParsedCounter(Int64 MailCount, Int64 AttchCount)
{
try
{
if (lblMailParsedCount.InvokeRequired)
{
Del_updateParsedCounter objUpdateParsedCounter = new Del_updateParsedCounter(UpdateParsedCounter);
this.Invoke(objUpdateParsedCounter, new object[] { MailCount, AttchCount });
}
else
{
lblMailParsedCount.Text = MailCount.ToString();
lblAttchSavedCount.Text = AttchCount.ToString();
}
}
catch (Exception ex)
{
Debug.Assert(false, ex.Message, ex.StackTrace);
}
}
I identified solution to issue but forgot that I raised a question here which wasn't answered.
Well issue was the background worker thread declaring a UIControl deep down somewhere in the code.
When a thread creates a UIControl it also registers itself with SystemEvents.UserPreferenceChanged event which notifies color, theme, screen size changes, system lock/unlock etc. and to respond to which parent thread requires a message pump lacking in background worker thread, the event invoke waits for a (never coming) response causing the application to hang or act non-responsive.
http://support.microsoft.com/kb/943139 link to Microsoft support explains the same.
I have a question about exception handling.
To prevent the "[YourProgram] has stopped working" Windows dialog, I usually catch even unhandled exceptions this way:
In App.xaml.cs:
protected override void OnStartup(StartupEventArgs e)
{
Application.Current.DispatcherUnhandledException += ProcessDispatcherException;
AppDomain.CurrentDomain.UnhandledException += ProcessUnhandledException;
// Blah blah blah... Performs a lot of loading operations...
mainWindow.Show();
}
and then
private void ProcessUnhandledException(object o, UnhandledExceptionEventArgs e)
{
logException("An unhandled exception has been thrown\n"+(e.ExceptionObject as Exception).ToString(), e.ExceptionObject as Exception);
Application.Current.Shutdown();
}
Okay, I don't have the Windows dialog. Now ideally I'd like to prevent this force closing scenario. The application I'm developing here has a startup time which lasts around 1 minute for the lightest users (most of them need to wait 2 or 3 minutes for launching it, it has to load a very large and complex data referential), so restarting it can cause trouble
I'd like to know about your "best practices" for this case. I am thinking about just re-creating a new window in the handler and re-show it anyway, so only the UI will be reinitialized to startup state, no other referential will be loaded, 2 - 3 minutes saved. Any other advices?
Oh and of course, this is the "extreme emergency case which should not be reached", but unfortunately it is, mostly due to our dependencies to other systems managed by other branches of the company with who I don't have any control or right to complain (yes, international companies can suck sometime), and it is not try/catchable in code :(
Thanks!
I am assuming from what you are writing that you want your application to be mission critical, meaning, if anything occurs that makes it fail, it needs to be restarted automatically.
The best way to accomplish this is to create a second watchdog process that will restart your application anytime it fails. You can then allow your application to quietly terminate itself when there is an unhandled exception, cleaning up whatever you can in your unhandled exception processor.
The simplest way to implement a watchdog like this is to have a no-window process (e.g., a console app) with a background thread loop that periodically checks that your application is running by checking if a wait handle is locked. Something like this:
// Declared in class
object checkLocker = new object();
bool mtStopCheck = false;
// Thread loop
bool stopCheck = false;
while (stopCheck == false)
{
if (wait_handle_is_unlocked)
restart_application();
Thread.Sleep(1000);
lock (checkLocker)
{
stopCheck = mtStopCheck;
}
}
When you want to shut the watchdog down another thread does this:
// Stop the watchdog thread so the watchdog app can shut down
lock (checkLocker)
{
mtStopCheck = true;
}
Since you'd be running in the same terminal session you don't need a global wait handle so no privilege issues on Vista/Windows 7.
If the user closes the application and you don't want it running again, you can send a signal to the watchdog process (e.g., with named pipes, or use a second kind of wait handle that you lock when you want the watchdog to suspend or shut down) that the app has been shut down and should not be restarted.
You can launch your watchdog in the startup folder or some other automatic method, or, you can have your app launch it the first time it runs.
As part of my App's startup procedure, it checks data integrity, and if it finds a problem it pops up a message to the user telling them that it might take a while to repair things.
I'm showing the message using MessageBox.Show. Because the data check is done from a worker thread, I'm switching over to the UI thread to make that call, and then setting a ManualResetEvent to tell the worker thread when the user has acknowledged the message.
I kick off the data check/load very early in the app's lifecycle from the constructor in the main Application class, by spinning off a worker thread (using the ThreadPool).
When I run with the debugger, and the message is displayed, the app just waits for input. When I run without the debugger, the app terminates after displaying the dialog for 10 seconds.
That 10 seconds is a big clue - it tells me that the OS thinks the app took too long to initialize (the OS kills apps that take too long to start up).
I think that my MessageBox.Show is blocking the UI thread before the App.RootFrameNavigating has a chance to be invoked.
My questions:
Does my diagnosis sound right?
I'd prefer to kick off my data load early, because it is almost entirely IO, except for this Message Box, and the sooner I can get my Model loaded, the better, but do you normally delay your data load until later in the app lifecycle?
Any other ideas/suggestions? I can't guarantee which page will be the start page, because the app could be resuming to any page. I'm also thinking of having the MessageBox.Show delay itself until the app has initialized, perhaps polling away for a flag set by App.RootFrameNavigating - does that make sense?
I think your problem is a result of kicking off the worker thread in the Application constructor. You should use the appropriate life-cycle event, in this case: PhoneApplicationService.Activated Event
So, the solution I've come up with is to still kick off the data load in a worker-thread from the Application's constructor, but in my PhoneService's class ShowDialog method that I invoke to invoke MessageBox.Show, I check to see if the initial navigation has occurred:
private readonly ManualResetEvent _appInitialized = new ManualResetEvent(false);
public void AppInitialized()
{
_appInitialized.Set();
}
public void ShowDialog(string caption, string text, Action<MessageBoxResult> callback, MessageBoxButton button = MessageBoxButton.OKCancel)
{
_appInitialized.WaitOne();
DispatcherHelper.CheckBeginInvokeOnUI(() =>
{
var result = MessageBox.Show(text, caption, button);
if (callback != null)
{
callback(result);
}
});
}
Then in my Application class:
private bool _firstNavigate = true;
private void RootFrameNavigating(object sender, NavigatingCancelEventArgs e)
{
if (_firstNavigate)
{
_firstNavigate = false;
var navigationService = (NavigationService) sender;
navigationService.Navigated += NavigationServiceNavigated;
}
....
private void NavigationServiceNavigated(object sender, NavigationEventArgs e)
{
var navigationService = (NavigationService)sender;
navigationService.Navigated -= NavigationServiceNavigated;
PhoneServices.Current.AppInitialized();
}
Anyone see any issues with this approach? Anyone come up with a better way?
Title's about it. WPF app with some WCF stuff for IPC. I call Application.Current.Shutdown() and the app continues on happily. I thought Shutdown was supposed to be unstoppable.
Perhaps because it's being called from a background thread? Do I need to do some dispatcher fiddling?
You get an exception when I call Application.Current.Shutdown in any thread other than the main one, so I'd assume you where using "dispatcher fiddling" properly already.
In any case, this compiles and quits an application, so if the dispatcher bit doesn't look like what you have you could sling it in:
ThreadStart ts = delegate()
{
Dispatcher.BeginInvoke((Action)delegate()
{
Application.Current.Shutdown();
});
};
Thread t = new Thread(ts);
t.Start();
In my experience all threads have to either be terminated explicitly or be marked as background threads in order for the application to close.
Here is an example of kicking off a read thread in the background:
_readThread = new Thread(new ThreadStart(ReadThread));
_readThread.Name = "Receiver";
_readThread.Priority = ThreadPriority.Highest;
_readThread.IsBackground = true;
_readThread.Start();
The IsBackground property is the key. Without that being set, the thread won't terminate on when you call Shutdown.
I only experience Application.Current.Shutdown not working when I'm running from Visual Studio. Within Visual Studio (at least the 2010 version I'm using) Application.Current.Shutdown doesn't do a thing. If I single step through it executes this line and then continues. If I run the program (as an .exe) from Windows Explorer then Application.Current.Shutdown works fine.
There is probably an explanation for this since during debug other threads are active, but I can't explain it.