I'm developing a Delphi application which calls a .net console application in hide mode, but the problem is: when I close my delphi application then the console application also closes, even using ShellExecute without specifying to wait for a SingleObject.
I tried that same Shell call for Windows Calc, so now even when I close my app the Calc remains opened and that is the behavior that I'm looking for.
Does someone know if it's possible to call a console application and leave it independent from parent process and how to do that, so it does not close when main application closes?
The issue is that the child process attaches to the console of the parent process. When the parent closes, it's console closes, taking the child with it.
Resolve this by giving the child process its own console. Use CreateProcess passing the CREATE_NEW_CONSOLE process creation flag. You will also want to pass CREATE_NO_WINDOW to avoid showing the new console window.
Related
I am trying to launch a process from my WPF application.The process is also a WPF application developed using PRISM/MEF framework.
var process = Process.Start(processPath);
process.WaitForInputIdle();
Console.WriteLine(process.MainWindowHandle);
//rest of the code
The problem is with PRISM/MEF application as process WaitForInputIdle() doesn't work.I tried printing mainwindowHandle and its zero after WaitForInputIdle().
Whereas I tried opening other process like notepad.exe ,WaitForInputIdle() works and prints the window handle.
Now I am using this workaround ,but can anyone tell why WaitForInputIdle() is not working properly?
var process = Process.Start(processPath);
process.WaitForInputIdle();
Console.WriteLine(process.MainWindowHandle)
while (process.MainWindowHandle == IntPtr.Zero)
{
Thread.Sleep(10);
}
//rest of the code
The Process.WaitForInputIdle() method just waits for the process's message loop to enter an idle state. Like your loop WaitForInputIdle() is also a workaround, it is not specifically coded to wait for the MainWindowHandle to be created. So depending on how the application works there's no guarantee that the window handle has been created by the time the method returns.
At least most of Windows's built-in apps uses the same methods as the Windows Forms applications for starting the app and creating the first window. In those cases the standard behaviour is that the process will enter an idle state when the window handle is created and the window is shown.
WPF, Prism and MEF works a bit differently than WinForms, thus there's no guarantee that the window handle has been created when the application finally enters an idle state. Unfortunately I'm not very much into WPF nor Prism or MEF, so I cannot even provide a theory about this behaviour.
The question here is if anyone has an idea how to both get StandardOutput data to print in Windows form application and keep the output in the console itself. The WinForms part I have completed already, it works great with process events and invoking form elements. At this point I am pretty sure that after re-directing output, Console.Writeline() doesn't print anything on the console window anymore. Any ideas besides running another dummy process that simply displays anything whats on InputStream?
Also
While I'm at this. Is there any way to access process that is on another thread? Since whenever I try to access it it shows that its out of scope.
I'm using C#/WPF, and generated a console programmatically using the WinAPI's Alloc/FreeConsole. When this is done, the standard System.Console class interacts wih it fine. Except, when you close the console by clicking the X rather than using FreeConsole(), it closes the rest of the app too. I'm using .NET 4- how can I override this behaviour?
This is just a guess, and it could be completely off, but does it have anything to do with Application.Current.ShutdownMode? Perhaps Application.Current.MainWindow is being set to the console, and ShutdownMode causes the application to terminate when the console window is closed?
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.
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.