We Keep Coding

MonitorFromWindow(DefaultToNearest) doesn't work during drag

I'm using the Windows API method MonitorFromWindow(hwnd, MONITOR_DEFAULTTONEAREST) as part of some overridden maximize functionality in my WPF application. One issue we've had with it is that the "nearest" window does not updating during drag operations (triggered by DragMove on the Window instance).
Suppose you drag the window between two screens of differing resolution and trigger the Aero Snap functionality on the second screen. This triggers a query on the window size (message WM_GETMINMAXINFO). Using MonitorFromWindow in this scenario returns the wrong screen. It's as if the data used by MONITOR_DEFAULTTONEAREST is not updated until the drag operation completes, and that doesn't complete until the resize function triggered by the Aero Snap completes. Is there some way to flush the current window position before answering the WM_GETMINMAXINFO query?

Since snapping is based on the mouse position, a solution to the problem would be to use GetCursorPos to get the current mouse position. Then pass that point to MonitorFromPoint to obtain the handle for the monitor that currently contains the mouse pointer.
A simple example:
[DllImport("User32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool GetCursorPos(ref Point lpPoint);
public const int MONITOR_DEFAULTTONEAREST = 2;
[DllImport("User32.dll")]
public static extern IntPtr MonitorFromPoint(Point pt, UInt32 dwFlags);
public IntPtr GetCurrentMonitor()
{
Point p = new Point(0,0);
if (!GetCursorPos(ref p))
{
// Decide what to do here.
}
IntPtr hMonitor = MonitorFromPoint(p, MONITOR_DEFAULTTONEAREST);
// validate hMonitor
return hMonitor;
}

Snap WinForm to program

Is it possible to do the following with WinForms/C#?
Dynamically detect window size and position of a running program (for example Notepad.exe)?
Snap WinForm to specific position within Notepad.exe?
Minimize and maximize WinForm window with other process (so when Notepad is minimize, so is WinForm window)?
See for example (black shape would be WinForm window):
Essentially I need to create a toolbar for a program, and the toolbar should "snap" to that program in the same place regardless of position or size of window.

First find the handle of the notepad window:
[DllImport("user32.dll", SetLastError = true)]
static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
Just pass null for the first parameter and the caption ("Notepad"?) of the window as the second parameter.
An alternative would be to enumerate all windows and select the best match based on the caption:
using System.Runtime.InteropServices;
public delegate bool CallBackPtr(int hwnd, int lParam);
private CallBackPtr callBackPtr;
public class EnumReport
{
[DllImport("user32.dll")]
private static extern int EnumWindows(CallBackPtr callPtr, int lPar);
public static bool Report(int hwnd, int lParam)
{
Console.WriteLine("Window handle is "+hwnd);
return true;
}
}
static void Main()
{
// note in other situations, it is important to keep
// callBackPtr as a member variable so it doesnt GC while you're calling EnumWindows
callBackPtr = new CallBackPtr(EnumReport.Report);
EnumReport.EnumWindows(callBackPtr, 0);
}
Then attach a WndProc to it:
HwndSource src = HwndSource.FromHwnd(windowHandle);
src.AddHook(new HwndSourceHook(WndProc));
In the WndProc respond to the resizing and moving of the window.
I am not sure about setting the toolbar as a child of the notepad window; that might have unexpected effects when Notepad tries to manage it and order its z-depth.
At the same time I doubt this to be a good thing; the user will be able to type 'below' the overlay and lose his cursor/text.

Find Notepad's window (FindWindow).
Create your window without borders.
Set your window as a child of Notepad's window (SetParent).
Your window will be anchored to the top left corner of Notepad's window. Minimizing will be handled automatically, but you'll need to resize your window when Notepad's window is resized (or maximized). You may also want to move Notepad's edit control.
WinForms can be used, but you'll need some interop calls.
I have to warn that this is not a very good idea. Your controls may conflict with controls inside host process's window, host process may rearrange controls the way you don't like, draw over your controls. In general, be ready to fight with numerous issues without a good clean solution, and to accept that there may be glitches when resizing etc.
See also:
Attach form window to another window in C#.

"Hiding" System Cursor

BACKGROUND:
I'm trying to create a "mouse hiding" application that hides the user's mouse from the screen after a set amount of time.
I've tried many things, and using SetCursor only hides the mouse from the current application, mine must be able to sit in the tray (for example) and still function.
I think I've found a solution with SetSystemCursor except for one problem.
MY PROBLEM:
I need to be able to capture any kind of mouse cursor, and replace the exact same kind of mouse cursor.
When replacing the mouse, I need to provide the id of the type of mouse I'd like to replace with the mouse referenced by the handle, but none of the functions I'm using provide me with the copied mouse's id (or type).
MY QUESTION:
Would it be sufficient to continue doing it this way, but move the mouse to 0,0 first, hiding it, and moving it back to it's original location upon un-hiding? (Unhiding is accomplished by simply moving the mouse)
Would a mouse at 0,0 always be an OCR_NORMAL mouse? (The standard arrow.)
If not, how could the mouse type/id be found to enable me to replace the proper mouse with the proper handle?
SOURCE:
[DllImport("user32.dll")]
public static extern IntPtr LoadCursorFromFile(string lpFileName);
[DllImport("user32.dll")]
public static extern bool SetSystemCursor(IntPtr hcur, uint id);
[DllImport("user32.dll")]
static extern bool GetCursorInfo(out CURSORINFO pci);
[StructLayout(LayoutKind.Sequential)]
public struct POINT
{
public Int32 x;
public Int32 y;
}
[StructLayout(LayoutKind.Sequential)]
struct CURSORINFO
{
public Int32 cbSize; // Specifies the size, in bytes, of the structure.
// The caller must set this to Marshal.SizeOf(typeof(CURSORINFO)).
public Int32 flags; // Specifies the cursor state. This parameter can be one of the following values:
// 0 The cursor is hidden.
// CURSOR_SHOWING The cursor is showing.
public IntPtr hCursor; // Handle to the cursor.
public POINT ptScreenPos; // A POINT structure that receives the screen coordinates of the cursor.
}
private POINT cursorPosition;
private IntPtr cursorHandle;
private bool mouseVisible = false;
private const uint OCR_NORMAL = 32512;
//Get the current mouse, so we can replace it once we want to show the mouse again.
CURSORINFO pci;
pci.cbSize = Marshal.SizeOf(typeof(CURSORINFO));
GetCursorInfo(out pci);
cursorPosition = pci.ptScreenPos;
cursorHandle = CopyIcon(pci.hCursor);
//Overwrite the current normal cursor with a blank cursor to "hide" it.
IntPtr cursor = LoadCursorFromFile(#"./Resources/Cursors/blank.cur");
SetSystemCursor(cursor, OCR_NORMAL);
mouseVisible = false;
//PROCESSING...
//Show the mouse with the mouse handle we copied earlier.
bool retval = SetSystemCursor(cursorHandle, OCR_NORMAL);
mouseVisible = true;

One application can't affect another applications cursor. You'd have to write a mouse driver of some sort in order to do this.

I found a good workaround for hiding system cursor temporarily that doesn't involve screwing around with setsystemcursor().
SetSystemCursor() is dangerous, because if the app crashes or otherwise throws a bug, the cursor will be changed permanently until the next reboot.
Instead, I implemented a transparent window over the whole desktop, and that window hides the cursor when needed. The method to use is ShowCursor from Win32.
The transparent window can be something like this:
http://www.codeproject.com/Articles/12597/OSD-window-with-animation-effect-in-C
[DllImport("user32.dll")]
static extern int ShowCursor(bool bShow);
ShowCursor(false);

Making a corner of the desktop activate screensaver

I am trying to write a simple application to activate my screensaver when the mouse in at the top right corner of the screen. I have found an answer to controlling the screensaver from C# however I am having trouble working out how to do a "hot corner" type check for the mouse position. This is the only part I am stuck with, any help would be appreciated.
This Activates the screensaver
[DllImport("user32.dll", EntryPoint = "GetDesktopWindow")]
private static extern IntPtr GetDesktopWindow();
[DllImport("user32.dll")]
private static extern IntPtr SendMessage(IntPtr hWnd, uint Msg, int wParam, int lParam);
private const int SC_SCREENSAVE = 0xF140;
private const int WM_SYSCOMMAND = 0x0112;
public static void SetScreenSaverRunning()
{
SendMessage(GetDesktopWindow(), WM_SYSCOMMAND, SC_SCREENSAVE, 0);
}

You could use the System.Windows.Form.Screen class to get the current resolution (take a look at this answer). Then use Cursor.Position.Property to determine where the cursor is currently located (i.e. is it within the boundaries of some predefined rectangle that should activate it).

I have made the exact same thing, only it loads in the top left. What I did was just make the form size 1px by 1px with no border, and just activate the screensaver when the mouse stays over the form for a second. Doing it this way requires that you find all ways to keep the form on top of everything.
Another option would be mouse hooking and just watching for (0,0) mouse position, or for the top right - (0, screen.width)

You could also try ScrHots from Lucian Wischik. It's freeware and does exactly what you need, and also has hot-corners for "never activate the screensaver" capability. All four corners can be programmed to do either function. I've used this one for years, and it works great.
http://www.wischik.com/scr/savers.html (ScrHots3, under the "Utilities" section)
Hope this helps someone.

How do I make a WPF window movable by dragging the extended window frame?

In applications like Windows Explorer and Internet Explorer, one can grab the extended frame areas beneath the title bar and drag windows around.
For WinForms applications, forms and controls are as close to native Win32 APIs as they can get; one would simply override the WndProc() handler in their form, process the WM_NCHITTEST window message and trick the system into thinking a click on the frame area was really a click on the title bar by returning HTCAPTION. I've done that in my own WinForms apps to delightful effect.
In WPF, I can also implement a similar WndProc() method and hook it to my WPF window's handle while extending the window frame into the client area, like this:
// In MainWindow
// For use with window frame extensions
private IntPtr hwnd;
private HwndSource hsource;
private void Window_SourceInitialized(object sender, EventArgs e)
{
try
{
if ((hwnd = new WindowInteropHelper(this).Handle) == IntPtr.Zero)
{
throw new InvalidOperationException("Could not get window handle for the main window.");
}
hsource = HwndSource.FromHwnd(hwnd);
hsource.AddHook(WndProc);
AdjustWindowFrame();
}
catch (InvalidOperationException)
{
FallbackPaint();
}
}
private IntPtr WndProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
{
switch (msg)
{
case DwmApiInterop.WM_NCHITTEST:
handled = true;
return new IntPtr(DwmApiInterop.HTCAPTION);
default:
return IntPtr.Zero;
}
}
The problem is that, since I'm blindly setting handled = true and returning HTCAPTION, clicking anywhere but the window icon or the control buttons causes the window to be dragged. That is, everything highlighted in red below causes dragging. This even includes the resize handles at the sides of the window (the non-client area). My WPF controls, namely the text boxes and the tab control, also stop receiving clicks as a result:
What I want is for only
the title bar, and
the regions of the client area...
... that aren't occupied by my controls
to be draggable. That is, I only want these red regions to be draggable (client area + title bar):
How do I modify my WndProc() method and the rest of my window's XAML/code-behind, to determine which areas should return HTCAPTION and which shouldn't? I'm thinking something along the lines of using Points to check the location of the click against the locations of my controls, but I'm not sure how to go about it in WPF land.
EDIT [4/24]: one simple way about it is to have an invisible control, or even the window itself, respond to MouseLeftButtonDown by invoking DragMove() on the window (see Ross's answer). The problem is that for some reason DragMove() doesn't work if the window is maximized, so it doesn't play nice with Windows 7 Aero Snap. Since I'm going for Windows 7 integration, it's not an acceptable solution in my case.

Sample code
Thanks to an email I got this morning, I was prompted to make a working sample app demonstrating this very functionality. I've done that now; you can find it on GitHub (or in the now-archived CodePlex). Just clone the repository or download and extract an archive, then open it in Visual Studio, and build and run it.
The complete application in its entirety is MIT-licensed, but you'll probably be taking it apart and putting bits of its code around your own rather than using the app code in full — not that the license stops you from doing that either. Also, while I know the design of the application's main window isn't anywhere near similar to the wireframes above, the idea is the same as posed in the question.
Hope this helps somebody!
Step-by-step solution
I finally solved it. Thanks to Jeffrey L Whitledge for pointing me in the right direction! His answer was accepted because if not for it I wouldn't have managed to work out a solution. EDIT [9/8]: this answer is now accepted as it's more complete; I'm giving Jeffrey a nice big bounty instead for his help.
For posterity's sake, here's how I did it (quoting Jeffrey's answer where relevant as I go):
Get the location of the mouse click (from the wParam, lParam maybe?), and use it to create a Point (possibly with some kind of coordinate transformation?).
This information can be obtained from the lParam of the WM_NCHITTEST message. The x-coordinate of the cursor is its low-order word and the y-coordinate of the cursor is its high-order word, as MSDN describes.
Since the coordinates are relative to the entire screen, I need to call Visual.PointFromScreen() on my window to convert the coordinates to be relative to the window space.
Then call the static method VisualTreeHelper.HitTest(Visual,Point) passing it this and the Point that you just made. The return value will indicate the control with the highest Z-Order.
I had to pass in the top-level Grid control instead of this as the visual to test against the point. Likewise I had to check whether the result was null instead of checking if it was the window. If it's null, the cursor didn't hit any of the grid's child controls — in other words, it hit the unoccupied window frame region. Anyway, the key was to use the VisualTreeHelper.HitTest() method.
Now, having said that, there are two caveats which may apply to you if you're following my steps:
If you don't cover the entire window, and instead only partially extend the window frame, you have to place a control over the rectangle that's not filled by window frame as a client area filler.
In my case, the content area of my tab control fits that rectangular area just fine, as shown in the diagrams. In your application, you may need to place a Rectangle shape or a Panel control and paint it the appropriate color. This way the control will be hit.
This issue about client area fillers leads to the next:
If your grid or other top-level control has a background texture or gradient over the extended window frame, the entire grid area will respond to the hit, even on any fully transparent regions of the background (see Hit Testing in the Visual Layer). In that case, you'll want to ignore hits against the grid itself, and only pay attention to the controls within it.
Hence:
// In MainWindow
private bool IsOnExtendedFrame(int lParam)
{
int x = lParam << 16 >> 16, y = lParam >> 16;
var point = PointFromScreen(new Point(x, y));
// In XAML: <Grid x:Name="windowGrid">...</Grid>
var result = VisualTreeHelper.HitTest(windowGrid, point);
if (result != null)
{
// A control was hit - it may be the grid if it has a background
// texture or gradient over the extended window frame
return result.VisualHit == windowGrid;
}
// Nothing was hit - assume that this area is covered by frame extensions anyway
return true;
}
The window is now movable by clicking and dragging only the unoccupied areas of the window.
But that's not all. Recall in the first illustration that the non-client area comprising the borders of the window was also affected by HTCAPTION so the window was no longer resizable.
To fix this I had to check whether the cursor was hitting the client area or the non-client area. In order to check this I needed to use the DefWindowProc() function and see if it returned HTCLIENT:
// In my managed DWM API wrapper class, DwmApiInterop
public static bool IsOnClientArea(IntPtr hWnd, int uMsg, IntPtr wParam, IntPtr lParam)
{
if (uMsg == WM_NCHITTEST)
{
if (DefWindowProc(hWnd, uMsg, wParam, lParam).ToInt32() == HTCLIENT)
{
return true;
}
}
return false;
}
// In NativeMethods
[DllImport("user32.dll")]
private static extern IntPtr DefWindowProc(IntPtr hWnd, int uMsg, IntPtr wParam, IntPtr lParam);
Finally, here's my final window procedure method:
// In MainWindow
private IntPtr WndProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
{
switch (msg)
{
case DwmApiInterop.WM_NCHITTEST:
if (DwmApiInterop.IsOnClientArea(hwnd, msg, wParam, lParam)
&& IsOnExtendedFrame(lParam.ToInt32()))
{
handled = true;
return new IntPtr(DwmApiInterop.HTCAPTION);
}
return IntPtr.Zero;
default:
return IntPtr.Zero;
}
}

Here's something you could try:
Get the location of the mouse click (from the wParam, lParam maybe?), and use it to create a Point (possibly with some kind of coordinate transformation?).
Then call the static method VisualTreeHelper.HitTest(Visual,Point) passing it this and the Point that you just made. The return value will indicate the control with the highest Z-Order. If that's your window, then do your HTCAPTION voodoo. If it's some other control, then...don't.
Good luck!

Looking to do the same thing (make my extended Aero glass draggable in my WPF app), I just came across this post via Google. I read through your answer, but decided to keep searching to see if there was anything simpler.
I found a much less code-intensive solution.
Simply create a transparent item behind your controls, and give it a left mouse button down event handler which calls the window's DragMove() method.
Here's the section of my XAML which appears over my extended Aero glass:
<Grid DockPanel.Dock="Top">
<Border MouseLeftButtonDown="Border_MouseLeftButtonDown" Background="Transparent" />
<Grid><!-- My controls are in here --></Grid>
</Grid>
And the code-behind (this is within a Window class, and so DragMove() is available to call directly):
private void Border_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)
{
DragMove();
}
And that's it! For your solution, you would have to add more than one of these to achieve your non-rectangular draggable area.

simple way is
create stackpanel or every thing you want for your titlebar
XAML
<StackPanel Name="titleBar" Background="Gray" MouseLeftButtonDown="titleBar_MouseLeftButtonDown" Grid.ColumnSpan="2"></StackPanel>
code
private void titleBar_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)
{
DragMove();
}