Not a very good idea… who knows what that
exe
is doing? In general case, this is impossible, in others — very difficult.
There are some special cases when it is quite possible. One such case is console application, when you simply need to get its output in your WPF UI. In this case, you run the child application using
System.Diagnostics.Process.Run
and redirect two streams:
stdout
and
stderr
. Please see my recent Answer for further information:
How to read from command prompt[
^]. This is a relatively simple task and will always work.
There is another remote opportunity: the
exe
is a .NET assembly. There can be a chance to use it as a regular .NET class library and run some code from this assembly from the host application. For .NET, the difference between EXE and DLL files is not significant; any EXE file can be referenced as a library. However, if the application to be used as a library is written cleanly, it won't export many types as public. In this case, all types and their members can be accessed through Reflection; and the EXE file should be loaded during run-time using
System.Reflection.Assembly.LoadFile
. A very deep knowledge of the structure of the application to be used will be needed to do this trick. If the source code of this application is available, there no point to do any tricks, if not — it may require a lot of research and experiments. Do you want to waste so much time without any guaranteed result?
All other possibilities seem to be much less realistic, even compared with the previous one; I would not discuss them.
[EDIT]
Some detail on suggestion by Prerak and Abhinav. This is what I called "very difficult". You can change the parent of the main window of the second (child) process. First problem: you cannot do it immediately after the process is started: the main window is not created at this moment. You need to trigger this surgery by something, maybe even timer, which would make the process highly unreliable (how knows how much time is enough? it depends on the system). Second problem is: the child application cannot guarantee correct operation after being re-parented. Next problem: you need some existing windows with a window handle to become a parent. You're using WPF: all the controls are not windows. You can use only top-level window (sorry, I'm not 100% sure; never tried) or you need to host a HWND-based control of
System.Windows.Forms
inside your WPF UI, which is a whole separate story (see
http://msdn.microsoft.com/en-us/library/ms751761.aspx[
^]).
If you do it all, your useful effect per effort is still miserable: all you gained is practically just coordination of window/application activation (for example, via ALT+Tab) with the host application.
Do you want to do it all for such effect? Very little compared to what you already have, I would say…
—SA