I need to resize a window larger than screen resolution or size of desktop, programmatically & preferably also manually.
Since MS-Windows XP/Vista disallows a wi
If you would like to resize a window that you do not own (and without using any kind of hook), you can use the Windows SetWindowPos API with the SWP_NOSENDCHANGING (0x0400) flag set:
BOOL WINAPI SetWindowPos(
__in HWND hWnd,
__in_opt HWND hWndInsertAfter,
__in int X,
__in int Y,
__in int cx,
__in int cy,
__in UINT uFlags // ** SWP_NOSENDCHANGING must be passed here **
);
This will prevent the WM_WINDOWPOSCHANGING message from being sent which is what triggers the WM_GETMINMAXINFO restriction. Any other sizing of the window will cause the restriction to snap the window back to desktop restricted sizes, as the message will be sent and the window size enforced.
The following is a tiny example program that will resize Notepad to 6000x6000 (change the string "Untitled - Notepad" to the title of the window you want to resize, or take the window name and desired size from the command line args)
namespace Example
{
class Program
{
[DllImport("USER32.DLL")]
public static extern IntPtr FindWindow(String className, String windowName);
[DllImport("USER32.DLL", SetLastError = true)]
public static extern bool SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter, int left, int top, int width, int height, uint flags);
static void Main(string[] args)
{
var TOP = new IntPtr(0);
uint SHOWWINDOW = 0x0040, NOCOPYBITS = 0x0100, NOSENDCHANGING = 0x0400;
var hwnd = FindWindow(null, "Untitled - Notepad");
SetWindowPos(hwnd, TOP, 0, 0, 6000, 6000, NOCOPYBITS | NOSENDCHANGING | SHOWWINDOW);
}
}
}
This approach is generally functional, but there are a number of limitations that might prevent a window from being resized, or resized in any useful manner.
Starting with Windows Vista, Microsoft has implemented increasing security around window messages. An executable can only interact with windows at or below its own security context. For example, to resize the "Computer Management" window (which always runs elevated), this program would have to run elevated as well.
Window sizes might be enforced passively or actively by a program. A window with a size enforced passively sets the initial size and simply exposes no ability for the user to resize the window (e.g., no size grip control). These windows can usually be resized by sending a message as described but, lacking layout logic, will not show anything other that additional empty client area.
Windows with active enforcement monitor the size, either by catching the windows messages such as WM_SIZE, or in more sophisticated layout logic. These windows may accept the message, but will restrict or limit the final size in their own code.
In either case, Windows with fixed sizes generally lack any layout logic to take advantage of larger sizes so, even if you can force it, resizing them confers no benefits.
The Window
class in WPF has an HwndSource
that handles window messages sent to the WPF window. The private method LayoutFilterMessage
catches the WM_SYSCOMMAND
, WM_SIZING
, WM_WINDOWPOSCHANGING
, and WM_SIZE
messages. In this case, the WM_SIZE
message is then handled by the private Process_WM_SIZE
which, in effect, bypasses the NOSENDCHANGING
flag and alters the RenderSize
of the WPF client area. This is part of an overall process of adapting legacy Win32 messages to WPF events.
The net effect is that the Win32 host window is resized (unless SizeToContent is set to SizeToContent.WidthAndHeight), but the WPF render area is locked to the desktop area, as if the NOSENDCHANGING flag weren't set. When the above code sample is run against a WPF app, you can see the 6000x6000 window in Aero Peek from the task bar or the window preview in the Windows-Tab switcher, but you can also see the WPF content and layout logic being clipped to the desktop area. In this way, the WPF window is like the actively enforced window but, rather than enforcing a specific size, enforces a specific maximum (for RenderArea) and does not consider the WM_WINDOWPOSCHANGING
message.
If it is your own app and you host the WPF within a Windows Forms window (via ElementHost
) you can resize the window and the WPF content will respect the larger-than-desktop Windows Form window.
Other frameworks such as GTK and Qt may or may not enforce size behavior and limits, and may have various workarounds possible to overcome those limits. Any given program may ignore, rewrite, or bypass a window message and a framework can enforce it across an entire class of application such as with WPF above.
More about the SetWindowPos API:
Reference Source for Process_WM_SIZE
method of HwndSource
:
http://referencesource.microsoft.com/#PresentationCore/Core/CSharp/System/Windows/Interop/HwndSource.cs,da4aa32ad121c1b9,references
If you have a video card with the possibility to connect more than one screen, another workaround is to setup your system as if it is using two screens next to eachother. Then you can resize your windows to the size of the two screens together.
Only the recommended screen resolutions are listed. For additional settings, click the Advanced
button on the Settings
tab, click the Adapter tab
, and then click List all Modes
. Select the resolution, color level, and refresh rate you want.
I've just did it, here you can find the answer in the last point.
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/display_change_screen_resolution.mspx?mfr=true