Is there a way to use a program as a MDI child window. I am thinking of having one main MDI parent window which can have multipe child windows, some of which will be programs(.exe files) in there own right.
Tim
There is actually a pretty easy way to do this.
First, you need to add a panel to your form. This panel will be used to "host" the application.
Next, you need to the "System.Runtime.InteropServices" and the "System.Diagnostics" namespace to your namespaces:
csharp
using System.Diagnostics;
using System.Runtime.InteropServices;
Now, we need setup our WinAPI functions:
[DllImport("user32.dll")]
static extern IntPtr SetParent(IntPtr hwndChild, IntPtr hwndNewParent);
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = false)]
static extern IntPtr SendMessage(IntPtr hWnd, Int32 Msg, Int32 wParam, Int32 lParam);
Now, inside a button click event, start the process, and set it's parent to the panel. In this example, I will be using notepad:
// Create a new process
Process proc;
// Start the process
proc = Process.Start("notepad.exe");
proc.WaitForInputIdle();
// Set the panel control as the application's parent
SetParent(proc.MainWindowHandle, this.panel1.Handle);
// Maximize application
SendMessage(proc.MainWindowHandle, 274, 61488, 0);
I have implemented a similar thing a few years ago (.NET Framework 1.1 based, if I recall correctly). Key elements of that implementation were:
We created an extended Form class that exposed some specific functionality, such as an interface for extracting user commands that would invoke the UI.
The main application would scan the dll's in the application directory and inspect them (using Reflection) to find any classes based on our special Form class, and extract information out of them to build menu structures that would invoke the commands.
When a user invoked a command that would lead to a form being displayed, it was created (using Activator.CreateInstance), stripped from form borders and embedded into a container (in our case a TabPage in a TabControl, in your case most likely an "empty" MDI Child form in your application).
This all worked out fairly well I think (I actually think that the framework is still being maintained and used within the company it was created for).
You may want to keep an eye at memory management. For instance, since an assembly cannot be unloaded, if that is a requirement you will need to load external assemblies into separate AppDomains. Also pay attention to any event handlers that are attached dynamically when child window UI's are loaded, so that they are properly detached when the UI's are unloaded.
Import the InteropServices and Threading namespaces
using System.Runtime.InteropServices;
using System.Threading;
Import SetParent from user32.dll
[DllImport("user32.dll")]
static extern IntPtr SetParent(IntPtr child,IntPtr parent);
Create a new process and make it an MDI child of our form using SetParent
Process proc;
// Start the process
proc = Process.Start("calc.exe");
proc.WaitForInputIdle();
Thread.Sleep(500);
// Set the panel control as the application's parent
SetParent(proc.MainWindowHandle, this.panel1.Handle);
Related
I want to set an application to be the child of my WPF application.
My application has 3 window and I would like all windows to be childs of the WPF.
I use this code enter code here
main:
[DllImport("user32.dll")]
private static extern IntPtr SetParent(IntPtr hWnd, IntPtr hWndParent);
loaded:
var helper = new WindowInteropHelper(this);
SetParent(proc.MainWindowHandle, helper.Handle);
It works just for one of the windows.
What should I do to have all windows in child of WPF?
Each control in WinForm has a unique handle, but WPF elements have not, To solve your problem you can put one or more WindowsFormsHost in the window and use handle of them because each WindowsFormsHost also has a unique handle the same as WinForm controls.
Then use SetParent like this :
SetParent(proc.MainWindowHandle, YourWindowsFormsHost.Handle );
I'm trying to obtain process information for the current active application (or window), using .Net/C#.
Currently I'm using
[DllImport("user32.dll")]
private static extern IntPtr GetForegroundWindow();
To get the current active window.
I understand there's no native way to do this other than use this API function.
From that, I use:
[DllImport("user32")]
private static extern UInt32 GetWindowThreadProcessId(IntPtr hWnd, out Int32 lpdwProcessId);
To get the process name that belongs to that window and then I get further process information.
I also use
[DllImport("user32.dll")]
private static extern int GetWindowText(IntPtr hWnd, StringBuilder text, int count);
To get the current Window Text or caption.
Now, using the Process class, I can use
MainWindowTitle
to get the main Window title as well.
The thing is, MainWindowTitle and GetWindowText does not return the same information.
For example, let's say the main application opened is "Toad" with a connection and an editor open.
Then with GetWindowText I get:
"Toad for Oracle - myConnection - Somequery.sql".
and Process.MainWindowTitle returns
"myConnection".
So, the question is how do I get the exact same text as I get using GetWindowText, but using merely .Net classes?
Edit:
I found out that actually the reason is simply because both functions are not querying the same window handle.
The window handle returned in the GetForegroundWindow, is the number 198982.
And the MainWindowHandle property, which I suppose is the one used in the MainWindowTitle propery is the number 198954.
Using Spy++ I could find and confirm those windows handle captions are the one returned by their corresponding function.
So the "problem", if any, is that the Process class does not correctly identify the most foreground window as the Main Window.
GetForegroundWindow gives you the active window the user is working in and that might be a owned window or a modal dialog, not necessarily the applications main/root window.
MainWindow is a .NET concept, native win32 does not have such a thing and there can be 0, 1 or multiple "main windows" in an application.
Some Delphi/C++Builder applications have a HWND for the taskbar button and each form is a owned window belonging to this "invisible" window. Other UI frameworks may pull similar stunts that might confuse "main window" detection.
You can use UI Automation to inspect other applications if you don't want to use p-invoke. Start with the foreground window and walk up the tree of owned and child windows...
So far I make a window - active, to send text using SendKeys, but I want to do it in background using SendMessage
IntPtr main = FindWindow(null, "Label Code (Scan)");
if (!main.Equals(IntPtr.Zero))
{
if (SetForegroundWindow(main))
{
SendKeys.SendWait(code);
SendKeys.SendWait("{ENTER}");
}
}
I have tried something like:
IntPtr main = FindWindow(null, "Label Code (Scan)");
SendMessage(main, 0x000C, 0, "Hello");
But it renames window's title to "Hello". Looks like, I need to find child window, but can't find out about lpszClass.
public static extern IntPtr FindWindowEx(IntPtr hwndParent, IntPtr hwndChildAfter, string lpszClass, string lpszWindow);
The controls in the window are not real Windows Controls. They are drawn and managed by the Window itselt. However, the window may support the Windows Automation framework to allow interacting with the controls.
Use the tool Inspect to check whether the window supports Windows Automation API.
If it does, use the classes in System.Windows.Automation with the information you see in the Inspect tool to set the text.
I work eg. in Firefox, and my C#.NET app brings its window to the front. That's ok, but when I use SendToBack() to hide the form, it doesn't activate Firefox's window, so altough Firefox is in the foreground, I have to click into the window to be able to scroll, etc. How can I activate the previously focused window in C#?
i have tried these:
[DllImport("User32")]
private static extern int SetForegroundWindow(IntPtr hwnd);
[DllImport("user32.dll")]
static extern bool AllowSetForegroundWindow(int dwProcessId);
[DllImport("user32.dll")]
static extern IntPtr GetForegroundWindow();
[...]
AllowSetForegroundWindow(System.Diagnostics.Process.GetCurrentProcess().Id);
SendToBack();
SetForegroundWindow(GetForegroundWindow());
I hoped that after sending my window back, the previous one will be returned by GetForegroundWindow, but it doesn't work.
Secondly, I've tried to override WndProc, and handle the WM_ACTIVATE message to get the previous window from lParam, but it doesn't work either if I use SetForegroundWindow() with this handle.
protected override void WndProc(ref Message msg) {
if (msg.Msg == 0x0006) {
prevWindow = msg.LParam;
}
base.WndProc(ref msg);
}
[...]
SetForegroundWindow(prevWindow);
did you try the SetActiveWindow function? Its separate from the SetForgroundWindow function, although it seems that you may need to use them both.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646311%28v=vs.85%29.aspx
There is also a SetFocus function which sounds like it could work.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646312%28v=vs.85%29.aspx
Update
To get the current Active Window, I would fire off the GetActiveWindow function before moving your application to the front of the stack, that way you have the handle for the window that was active before hand.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646292%28v=vs.85%29.aspx
Another Update
I did a bit more digging around on the site and came up with the following three links, which might work better. The keyboard input functions seem to be dependent on the Window you are trying to set being part of the calling threads message queue, which since we are dealing with two separate application threads, is likely to not be the case.
GetGUIThreadInfo Get the threads information, including active window
GUITHREADINFO The GUITHREADINFO structure
SwitchToThisWindow Another method of window changing
All of these are in the same method stack as the SetForegroundWindow method, which seems to make them more likely to do what you are attempting.
When you call SetFocus() to move your app forward, it returns the handle of the window that had focus before you.
How I can keep my window staying always on top even if there is a window of another application with Topmost = true option activated and trying to stay in front of my window?
You can do a platform invoke on BringWindowToTop to achieve this:
[DllImport("user32.dll", SetLastError=true)]
static extern bool BringWindowToTop(IntPtr hWnd);
[DllImport("user32.dll", SetLastError=true)]
static extern bool BringWindowToTop(HandleRef hWnd);
And call to it when the FocusLost event fires.
It should be possible by setting the Focus on window, from OnFocusLost event handler.
Easiest way(assuming you allready have topmost promery set) would be calling
myform.BringToFront();
on FIXED but relativly small time intervals(see Timer class), through all the time form must stay on top.
If calling this was conected to event that inform you of losing privileg of beeing on top, that could possibly cause resource-fihgts between multiple applications. Price of beeing safe is that some other program might be cheating by lisstening to informations when he is overthroned by your program, but the only solution for you wolud than be to kill that other program if you want to stay on top all the time :D