I am designing a Windows 10 Universal application using this https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/Printing/cs repository as a guide. I currently have fully functional printing by calling:
await Printmanager.ShowPrintUIAsync();
In my application there is also an activity timer that logs the user out after a certain amount of time inactive. This part is working fine, but I am unable to close the print ui upon logout.
Note: Normally to close a windows async operations, you can do something similar to:
IAsyncOperation<bool> printOperation = Printmanager.ShowPrintUIAsync();
printOperation.Cancel();
This works for other AsyncOperation occurences, but I cannot get it to work for the print UI, as the print UI is not a child process of the app, but is a seperate process itself
Thanks in advance!
Also, it seems there was a solution to kill processes in Windows 8 which is no longer supported in Windows 10 applications (Process.GetProcessByName .... or FindWindow)
Perhaps there is someway to kill a Windows 10 process by name?
You can't do that.
All the Metro-style applications work in the highly sandboxed environment and there is no way to directly start an external application.
Taken from this article
maybe the solution is creating a proxy.
How to Start a external Program from Metro App
This could help you, because you can kill the process indirectly.
I hope this helps.
Related
This question already has answers here:
How to do something before process get killed in windows
(3 answers)
Closed 5 years ago.
Is there anything I can do with my program wherein I have to do something when my application has been terminated using task manager?
I hope you can help me in this matter.
Thank you!
You can´t do this because the applications process is forcefully closed (killed). Events only happen if the application is asked to end e.g. call Close() or Exit().
If you need to do something when this happens implement a different app that monitors your app to take actions e.g. restart app or close another app.
I have a windows application that shells an outside application (.exe). What i want to achieve, is when the user terminates my windows application thru task manager, the shelled outside application should also be terminated.
As pointed out by others, you simply cannot do this, because when a process is killed, it receives no events at all. What you can do, however, if this requirement is super important, that you deploy a second program, which is a windows service, that monitors your windows app and shuts down the shelled application whenever it finds that your app is not running any more.
Is it possible to run applications on the Windows Desktop? I mean... that it can only be seen in the system tray, and it should be able to run alongside the desktop.
I have no idea how to code it, please help me. I'm kind of new to these things, I am supposed to create something like a "Stardock Fence".
I have seen some examples, but they seem buggy, any strong alternative I could use?
Process.Start() can be used to start a windows application/console app from another win application. There are parameters that allow you to optionally hide the UI as well.
You want your application's windows to be always-on-bottom. In other words, your UI will always appear to be beneath any other open window and just above the Desktop's icons.
To accomplish that, see these related questions.
Once you have a window always on the bottom of the z-order, you'll probably want to remove the non-client window chrome (titlebar/min/max/close buttons) so that your UI can look like a more integrated part of the Desktop. There's plenty of examples around; Googling is left as an exercise for the reader.
Not entirely sure what you mean by background. I expect you mean a Windows Service which is a project type in visual studio, or you might (less likely) mean running a background thread.
Actually, if you want it in the system-tray, you don't want it entirely in the background.
If it was to be fully "in the background", then your best bet is to have it as a service.
System tray icons need a window, but you can just make it non-visible and non-taskbar and that's fine.
A common combo is a service that does the actual heavy-lifting, and a hidden-window application with a systray icon that reports on the service's status (possibly making that same window visible when further interaction is needed).
You want to run your application in the background? Is it on a windows machine? If so then you want to look into running your application as a windows service. Here's an msdn link:
Introduction to Windows Services
There's examples in the article I think - if not it's a good starting point. You can configure services to start automatically on startup of the machine etc. Your application will then run in the background.
Basically you craete your application as normal and then host it in a windows service rather than say a console app or a winforms app.
I've a small c# application which does some sync between two libraries.
This has to run regularly, and the use of scheduled has been choosed.
So for now everything is working fine, except one thing, when the task is scheduled, I got a console windows which opens.
Is there any way(in the scheduler or in the application) to don't have any windows visible when the program is running?
My sync library can put in what I want.
(what if instead of using a console application, I create a windows application, without any windows, and the code started in the app.xaml.cs ? Is this a good idea? I've the impression this isn't the right way to do it).
Thank you!
In the Project Properties window, Change the output type from Console Application to Windows Application. Your application will still run, but it will have no window at all. You might also consider making a Windows Service instead.
Set up the task to run as a different user, then it won't popup to the currently logged in user. You could run it as SYSTEM i.e.
Yes, using a Windows App without any windows is the way to go. You can even show a tray icon in an app without windows if that might be useful.
This program should not have a visible window, more like a daemon. (a taskbar program for instance) Any links or advice will be appreciated.
You might want to consider writing a Windows Service.
If you just need to execute a specific action at certain times you could make use of the Windows Task Scheduler.
If you want an icon in the system tray you could write an ordinary Windows Forms application but have the main form hidden until the user requests it. This article explains how.
Or if you want to run tasks on a timer, the Windows Task Scheduler's where it's at.
When I've built applications that need this functionality before, I've always used the Windows Task Scheduler through a simple .NET library that I found.
Please see my answer to a similar question for some sample code and more explanation.
Background:
Started a fair amount of work before realizing that a Windows Service cannot start an app with a GUI that displays without potential problems. The proper solution of separating the GUI of the app to be started is non-trivial, so I'm trying to think of alternative solutions.
There is a GUI to manage the service that is a separate executable, but the process to be launched (actually multiple instances of it) has its own GUI that needs to be shown. It doesn't need to be made visible by the service itself, but it needs to be at least able to be made visible by another process with a visible GUI. The Windows User that is running the service and that needs to see the GUI of the launched process is the same and known at install time.
Is there some way to accomplish this or is it back to the drawing board?
Also both the service and the app to launch are both our code and modifiable.
My first thought was to suggest that you look at the WTS* functions and CreateProcessAsUser and then I followed the link you provided and saw that you have already considered this and dismissed it.
As an alternative, if I understood you correctly you have a Windows Service and GUI which is used to manage the service. So why not use the communication channel you have between the Service and the management GUI to send a message from the service to the management GUI and have the management GUI launch the other GUI apps on behalf of the service? Of course this would assume that the management GUI is always running.
You might even do this with a hidden application that is not visible and launches when the user logs-in, that way you reduce the risk of the user inadvertantly closing the application, this would be a separate app from the actual management application.