In WPF, I have used this code to control the process of an external .exe file:
ProcessStartInfo info = new ProcessStartInfo()
{
Verb = "runas",
FileName = executePath,//Client.exe path within the WPF application
UseShellExecute = false,
RedirectStandardError = true,
RedirectStandardOutput = true,
};
Process scanProcess = new Process
{
StartInfo = info,
EnableRaisingEvents = true
};
int procId = Process.GetCurrentProcess().Id;
Process[] existingProcess = Process.GetProcessesByName("Client.exe");
foreach (Process process in existingProcess)
{
if (process.Id == procId)
{
continue;
}
return;//don't run, might have tried to start double
}
scanProcess.Start();
scanProcess.Exited += (s, e) => GoBack();
windowHandle = IntPtr.Zero;
IntPtr buttonHandle = IntPtr.Zero;
while (buttonHandle == IntPtr.Zero)//wait till process is fully started, we wait for a button the be available because then we know it is ready
{
windowHandle = HardwareApi.GetForegroundWindow();
buttonHandle = HardwareApi.FindWindowEx(windowHandle, IntPtr.Zero, "TPanel", "Start");
}
Rectangle rect = new Rectangle(0, 0, 0, 0);
HardwareApi.GetWindowRect(windowHandle, ref rect);
//move window to correct position
var tempX = 500;
var tempY = 600;
HardwareApi.SetWindowPos(windowHandle, new IntPtr(-1), 0, 0, 0, 0, 3u);
HardwareApi.MoveWindow(windowHandle, (int)tempX, (int)tempY, rect.Width, rect.Height - 55, true);
As you see, quite a bit of intense process controlling. HardwareApi is just a collection of user32.dll methods using DllImport.
Now I don't mind if not all of these functionalities are possible, but at least I need to be able to start the process and stop it/kill it from out the new UWP application.
So I went through the process of creating an UWP application and a Package application, I followed this blog, provided by this answer on stackoverflow. What is importantly different is that I do not have a separate Visual Studio Project of the external Client.exe, so I did what the mentioned answer said: Copy the Client.exe file (and the dependent files) into the Package project.
Solution view:
Package.appxmanifest of the Package project includes this part:
<Applications>
<Application Id="App"
....
<Extensions>
<desktop:Extension Category="windows.fullTrustProcess" Executable="Rss\Hardware\Software\RedFolder\Client.exe"/>
</Extensions>
</Application>
</Applications>
<Capabilities>
<Capability Name="internetClient" />
<rescap:Capability Name="runFullTrust" />
<rescap:Capability Name="allowElevation" />
</Capabilities>
And within the UWP application, I somewhere start the FullTrustProcess
Don't forget to go to Add Reference-> Universal Windows -> Extensions -> Windows Desktop Extensions for the UWP (latest version) and add the reference
if (ApiInformation.IsApiContractPresent("Windows.ApplicationModel.FullTrustAppContract", 1, 0))
{
await FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();
}
So this all works fine, so now the question is how I can do the following things:
Check if the process is running
Close the process at a certain time from within the UWP application
Move the window to a certain on-screen position (or use other user32.dll-like functions.
As per my understanding, App Service within UWP doesn't seem to be a solution, I can't modify the external .exe in such a way that it would receive/connect. If an App Service can be used from only the UWP-side to control a process then that would be great.
To solve your scenario you need to add a full-trust launcher/controller EXE to your package. Launch this from the UWP via FullTrustProcess launcher and communicate with it via AppServiceConnection. From the controller EXE you can then use all the System.Diagnostis.Process* APIs to start, check and kill your actual app process (Client.exe in your example) - and also use all the user32 function for window manipulation etc.
More info and a sample app on handling multiple processes here:
https://stefanwick.com/2018/04/06/uwp-with-desktop-extension-part-2/
Info and sample on how to do the communication here:
https://stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3/
A pure UWP app runs in a sandbox and cannot kill processes using the System.Diagnostics.Process type in .NET.
What you probably want to is to package your current WPF application as a UWP using a Windows Application Packaging project.
You will then be able to run it as a full-trust application but still take advantage of the streamlined deployment and update experience that UWP brings, as well as using modern UWP APIs side-by-side with your current .NET code.
Related
I have an Ionic / Cordova application hosted in the Windows UWP application, and which I am looking into swapping to host within a WPF application (latest .net, eg 6.0), and using WebView2.
Note, the Ionic/Cordova part is not really relevant to this question, this is purely related to WPF.
When running on a Tablet (eg Microsoft surface), I need to resize the app when the soft keyboard is shown, and hidden.
When in UWP, I could hook into the following events in my TypeScript file...
let w = <any>window;
const inputPane = w.Windows.UI.ViewManagement.InputPane.getForCurrentView();
if (!inputPane) {
this.logger.error('WindowsKeyboardService.hookupKeyboardHandlers: could not get inputPane');
return;
}
inputPane.addEventListener('showing', _ => this.onWindowsKeyboardUp);
inputPane.addEventListener('hiding', _ => this.onWindowsKeyboardClose);
So I won't have the WinJS any longer in the WPF, so I will do all the native in the WPF and then call into the JS myself using the appropriate API on the webview.
If I was in UWP, I could do something like the following:
System.Windows.UI.ViewManagement.InputPane.GetForCurrentView().Showing += (s, args) =>
{
GeneralTransform gt = loginButton.TransformToVisual(this);
Point buttonPoint = gt.TransformPoint(new Point(0, loginButton.RenderSize.Height - 1));
var trans = new TranslateTransform { Y = -(buttonPoint.Y - args.OccludedRect.Top) };
loginButton.RenderTransform = trans;
args.EnsuredFocusedElementInView = true;
};
But in WPF, I do not seem to have the `System.Windows.UI namespace:
Is there an equivalent way of doing this within a WPF application?
Update 1
I found this sample code
The whole solution will build in .net framework (4.7), but not in .net 6, as still missing the namespace Windows.UI. Perhaps this is renamed to something?
Update 2
I create a new WinUI project. Calling
var pane = Windows.UI.ViewManagement.InputPane.GetForCurrentView();
gives the same Element Not found error. I call this in a button click event, to give the main app/Window plenty of time to be fully initialized.
Note I am trying this out running from Visual Studio (i.e. Desktop Windows 10), and not on an actual tablet at this stage.
I this similar post where there is a comment
#LeftTwixWand ApplicationView.GetForCurrentView and CoreApplication.GetCurrentView() are only for UWP apps. For WinUI 3 desktop apps, use the Window class for some of the functionality. I'm not completely sure but some of them also now a GetForWindowId method.
It mentions using the Window class, but there is nothing on how to do what I am after here (monitoring the soft keyboard show/hide events).
Update 3
Following #Victor below, I added the code and it asks me to install
#Victor is this correct?
For WPF you just need to use net6.0-windows10.0.17763.0 target framework or newer. APIs will be available for you via existing Interop classes. Do not use System.Runtime.InteropServices.WindowsRuntime, it is .net framework approach.
IntPtr handle = new WindowInteropHelper(window).Handle;
InputPane inputPane = InputPaneInterop.GetForWindow(handle);
I am trying to embed an external program in my exe using C#. This seems to work in a few cases but not in others. Is there a difference between the 2 EXE's?
Here is my code.
Process p = new Process();
p.StartInfo.FileName = "calc.exe"; // Does not work.
// p.StartInfo.FileName = "notepad.exe"; // works.
p.Start();
if (!p.HasExited)
{
p.WaitForInputIdle();
SetParent(p.MainWindowHandle, this.panel1.Handle);
bool ret = MoveWindow(p.MainWindowHandle, 0, 10, this.panel1.Width, this.panel1.Height - 10, true);
}
I have also tried adding & removing WaitForInputIdle & Thread.Sleep. But it doesn't seem to change the behavior.
Behavior:
Notepad.exe: The application opens inside the panel. I can drag it around within the panel but it does not go beyond the panel
Calc.exe: Opens outside the process. It is not bound to the panel.
I have 3 exe's provided by the customer that needs to be embedded. I am using "calc.exe" and "notepad.exe" only for the purpose of providing a reproducable code.
OS: Windows 10
Visual Studio Community Edition: 16.9.4
If C# is not the way to go, any suggestions on what would best suit this requirement.
Thank you.
Edit 1:
Based on few more search, I changed the style from WS_POPUP to WS_CHILD. But still not success.
Remove parent of window or form
Code:
uint style = GetWindowLong(p.MainWindowHandle, GWL_STYLE);
style = (style | WS_POPUP) & (~WS_CHILD);
SetWindowLong(p.MainWindowHandle, GWL_STYLE, style);
One strange thing I found though was that GetParent was always returning 0 (meaning root application), but SetParent was returning a different result. I thought SetParent should return the current parent, which would be same as GetParent.
Any clue will be appreciated.
We have a desktop Windows app (written in WFP/C#) that we distribute as a single .exe file with no installer (it bundles all its dependencies via a Fody/Costura plugin).
We would like to integrate a local Action Center toast functionality where the app can display a toast and respond to it when it's clicked.
Displaying the toast is straightforward and can be done by using the Microsoft.Toolkit.Uwp.Notifications nuget package. However, in order to actually receive proper notifications when the toast is clicked in the Action Center (as opposed to the balloon tip) we need to register with notification platform.
The guide on how to do this seems to be focused on apps with an installer (e.g. Wix): https://learn.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/send-local-toast-desktop?fbclid=IwAR2AoHRKI88VNGRG-pTUytwhkMuovWT4bEr0RoXEayWpWsoGlghtZeq4Mo4#step-4-register-with-notification-platform
The specific task we're trying to achieve is, from the documentation:
If you're using classic Win32 (or if you support both), you have to declare your Application User Model ID (AUMID) and toast activator CLSID (the GUID from step #3) on your app's shortcut in Start.
How can we do it without writing an installer? We would like our app to do this registration on first run.
Note: the app already has provisions for elevating itself through UAC if needed by restarting itself in Administrator context.
Additional references: WPF native windows 10 toasts
[Update]
I managed to follow the instructions in https://learn.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/send-local-toast-desktop
and https://learn.microsoft.com/en-us/windows/win32/shell/enable-desktop-toast-with-appusermodelid to put together what should have been a working solution, but in the end, clicking on toasts in the Action Center does not trigger OnActivated() in my NotificationActivatior.
Salient points:
Sending notification
var toast = new ToastNotification(toastXml);
DesktopNotificationManagerCompat.CreateToastNotifier().Show(toast);
Registration:
string shortcutPath = Path.Combine(
Environment.GetFolderPath(Environment.SpecialFolder.Programs),
"Toasty.lnk");
DesktopNotificationManagerCompat.RegisterAumidAndComServer
<MyNotificationActivator>(AppName);
DesktopNotificationManagerCompat.RegisterActivator
<MyNotificationActivator>();
if (!File.Exists(shortcutPath))
{
ShortcutManager.RegisterAppForNotifications(
shortcutPath,
Assembly.GetExecutingAssembly().Location,
null,
AppName,
ActivationId);
}
Creating a shortcut
public static void RegisterAppForNotifications(
string shortcutPath,
string appExecutablePath,
string arguments,
string appName,
string activatorId)
{
var shellLinkClass = new ShellLinkCoClass();
IShellLinkW shellLink = (IShellLinkW)shellLinkClass;
shellLink.SetPath(appExecutablePath);
IPropertyStore propertyStore = (IPropertyStore)shellLinkClass;
IPersistFile persistFile = (IPersistFile)shellLinkClass;
if (arguments != null)
{
shellLink.SetArguments(arguments);
}
// https://learn.microsoft.com/en-us/windows/win32/properties/props-system-appusermodel-id
propertyStore.SetValue(
new PropertyKey("9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3", 5),
new PROPVARIANT(appName));
// https://learn.microsoft.com/en-us/windows/win32/properties/props-system-appusermodel-toastactivatorclsid
propertyStore.SetValue(
new PropertyKey("9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3", 26),
new PROPVARIANT(new Guid(activatorId)));
propertyStore.Commit();
persistFile.Save(shortcutPath, true);
}
[Update]
Finally got it to work - not sure what was wrong before, but the final version seems to be okay. Full code: https://gist.github.com/davidair/c4ea207bf6eece4ef08b97ab29a3036f
I have the same problem with my project now.
Managed to find this repository - https://github.com/felixrieseberg/electron-windows-interactive-notifications
Here's C++ implementation for installing shortcut (InteractiveNotifications file, InstallShortcut method). I guess the problem is how we set the value to PropertyStore, string GUID is not suitable for some reason. Still, I wasn't able to solve the problem for now.
UPDATED: Finally, was able to install shortcut from code! Check my example at Github. https://github.com/romayavorskyi/WpfNotificationTest (still a lot of hardcode, but it should give you the general idea). And you were right, shortcut path matters. It seems shortcut should be in the ProgramData folder for correct work.
I have a UWP app that does the recording and calling functionality. For this I have added two FullTrust Apps using Desktop bridge application. When I call just one fullTrust app everything works perfectly, but when I call two FullTrust apps by passing parameters (of the FullTrust apps to be started) the the first app that was started behaves incorrectly. For these two FullTrust apps I have used two different Appservice names declared in the Package.Manifest file of the Windows Packaging Project.
I have noticed that whenever I switch the position of the Fulltrust app call the last application that is called always remains active(has the priority of the Appservice connection) even if both has different app service names.
Here is the code I have added when user opens a page in UWP that starts Win32 app and background App
if (ApiInformation.IsApiContractPresent("Windows.ApplicationModel.FullTrustAppContract", 1, 0))
{
await FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync("Win32");
}
if (ApiInformation.IsApiContractPresent("Windows.ApplicationModel.FullTrustAppContract", 1, 0))
{
await FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync("Background");
}
In the above code, the first app that is Started calls my Win32.exe and second background.exe.
How can I call these two apps independently? whenever we want to start them and close whenever required or may be in future I would like to start two apps at the same time but also I may need to close any app whenever required. Can anyone tel me how can I handle the correct communication path when calling two fullTrust apps at the same time?
How can I call these two apps independently?
For launching multiple desktop app, we suggest to make Launcher app to manage multiple apps, then call LaunchFullTrustProcessForCurrentAppAsync(string parameterGroupId) and pass GroupId parameter. And at first we need add the group in the desktop bridge appxmanifes file.
<Extensions>
<desktop:Extension Category="windows.fullTrustProcess" Executable="Launcher\Launcher.exe">
<desktop:FullTrustProcess>
<desktop:ParameterGroup GroupId="Background" Parameters="/background" />
<desktop:ParameterGroup GroupId="Win32" Parameters="/win32" />
</desktop:FullTrustProcess>
</desktop:Extension>
</Extensions>
Then use the Launcher to start all apps with parameter
static void Main(string[] args)
{
// determine the package root, based on own location
string result = Assembly.GetExecutingAssembly().Location;
int index = result.LastIndexOf("\\");
string rootPath = $"{result.Substring(0, index)}\\..\\";
// process object to keep track of your child process
Process newProcess = null;
if (args.Length > 2)
{
// launch process based on parameter
switch (args[2])
{
case "/background":
newProcess = Process.Start(rootPath + #"FullTrust_Background\FullTrust_Background.exe");
break;
case "/win32":
newProcess = Process.Start(rootPath + #"FullTrust_Win32\FullTrust_Win32.exe");
break;
}
}
}
For more detail please refer this tutorial.
I'm writing an utility (http://reg2run.sf.net) which in case execution without arguments works as windows application (shows OpenFileDialog, etc), otherwise - as console application.
So, in first case I don't want to show a console window, that's why project is Windows Application.
But in second - I need to show it, and it's created with
if (ptrNew == IntPtr.Zero)
{
ptrNew = GetStdHandle(-11);
}
if (!AllocConsole())
{
throw new ExternalCallException("AllocConsole");
}
ptrNew = CreateFile("CONOUT$", 0x40000000, 2, IntPtr.Zero, 3, 0, IntPtr.Zero);
if (!SetStdHandle(-11, ptrNew))
{
throw new ExternalCallException("SetStdHandle");
}
StreamWriter newOut = new StreamWriter(Console.OpenStandardOutput());
newOut.AutoFlush = true;
Console.SetOut(newOut);
Console.SetError(newOut);
And what I want - is to grab parent process standard output and use it, if it exists (in case execution via cmd.exe or Far Manager). How can I do it?
I tried
static Process GetParentProc()
{
int pidParent = 0;
int pidCurrent = Process.GetCurrentProcess().Id;
IntPtr hSnapshot = CreateToolhelp32Snapshot(2, 0);
if (hSnapshot == IntPtr.Zero)
{
return null;
}
PROCESSENTRY32 oProcInfo = new PROCESSENTRY32();
oProcInfo.dwSize = (uint)Marshal.SizeOf(typeof(PROCESSENTRY32));
if (!Process32First(hSnapshot, ref oProcInfo))
{
return null;
}
do
{
if (pidCurrent == oProcInfo.th32ProcessID)
{
pidParent = (int)oProcInfo.th32ParentProcessID;
}
}
while (pidParent == 0 && Process32Next(hSnapshot, ref oProcInfo));
if (pidParent > 0)
{
return Process.GetProcessById(pidParent);
}
else
{
return null;
}
and
StreamWriter newOut = GetParentProc().StandardInput;
but got InvalidOperationException: StandardIn has not been redirected. Because of
GetParentProc().StartInfo.RedirectStandardOutput = false
There are several approaches for applications that need to choose whether to act as console or GUI applications, depending on context, on Windows:
Have two separate applications, and have one conditionally start the other.
A variant of the above strategy, have two applications, one called 'app.com' (i.e. just rename a console EXE with COM extension) and the other called 'app.exe', so that command-line invocations will find app.com first. Because of ancient DOS compatibility, .COM executables are found before .EXEs. (This in configurable in Windows; see the PATHEXT environment variable.)
The rxvt/Cygwin technique, which is one I haven't really seen documented anywhere else.
Let me go into a little bit of detail about how rxvt on Cygwin works. Rxvt is a terminal emulator that normally runs on the X Window system. Because of the limitations of the Win32 console, Cygwin packages it as a more fully-featured console, with support for things like lots of lines of history, dynamic resizing, per-instance configurable fonts and colour themes, non-application-freezing mouse select and copy, etc. In order to run natively on Windows, rxvt shipped with Cygwin includes a tiny X11 wrapper library for Win32. Rxvt on Windows is actually a console application for compatibility reasons with existing native Win32 executables, but most of the time you never see the console; you just see the rxvt terminal emulator window itself.
The way it works is specifically implemented in rxvt/W11/wrap/wrap.c in the rxvt source tree, in the function called hideConsole(). Basically, it opens up its console (with a CreateFile("CONOUT$" ...)), and checks to see if the cursor position is at (0,0) (using GetConsoleScreenBufferInfo() on the console handle).
If it is, then it infers that it has been started as a standalone application, rather than from a console parent application, and thus it knows the OS has created a dedicated Win32 console for the process. It proceeds to hide this console window, but it has to find it first. It uses SetConsoleTitle to set the console window's caption to a unique value based on the name of the application and the current thread ID. It then uses FindWindow to find this window's handle (periodically Sleeping for a few ms if necessary for the title to change, because the console windows are actually controlled by a different process entirely in Windows). When it eventually finds the window handle, it hides it with ShowWindowAsync, passing in SW_HIDE.
Using this approach, you can write an application that:
if started from a console parent, it can continue to use this console
if started as an application, it can optionally choose whether or not to hide the console
The only downside is a very brief flash of a console window at application startup.
You can always the following P/Invoke method:
[DllImport("kernel32.dll")]
static extern bool AttachConsole(int dwProcessId);
const int ATTACH_PARENT_PROCESS = -1;