I'm working on my own software to operate the mouse on my computer using C# and the kinect SDK. I really want to try using it to play a game like Red Alert, or some sort of RTS, or even just for general navigation.
The problem that I've found is that when using a program with a different mouse, like red alert or going into a virtual machine where mouse integration isn't supported, the program will not pick up on the calls that the C# program is making to the System.Windows.Forms.Cursor calls, let alone the mouse_event calls. I'm new to interfacing with windows and what is happening here, can someone explain/pose a solution?
--UPDATE--
As an update, I'm still not entirely sure what's going on, but I seem to have found a workaround for red alert in particular;
Since red alert is a fairly low graphics program, it is trivial to run it within a virtual machine specifically for me, vmware workstation with an XP client. If you use the mouse_event code it works well, HOWEVER, something that I struggled with was finding the correct code to represent mouse movement. It would seem that the MOVE flag moves the mouse relatively, which I didn't want, and the absolute tag didn't move the mouse at all. It is, in fact, the OR of them that produces absolute movement on the screen, so my code for mouse movement and clicking emulation ended up looking like this:
mouse_event((int)0x00000002, cursor.X, cursor.Y, 0, 0);
for clicking and
mouse_event((int)(0x00000001 | 0x00008000), x, y, 0 0);
for mouse movement, where x and y are the new coordinates out of 65535 (the absolute range). Is it perfect? Nah. But it works for now. I think there's something to do with the way windows ignores certain programs when it runs ra, maybe because of compatibility mode? I don't have another game to test it with right now, but I'll post results with a non-compatibility mode in the future.
Pete
(It wouldn't let me post as an answer for another two hours and I have to sleep to catch a flight in the morning!)
You will have to do some low level windows messages to get this to work properly. Games using DirectX like Red Alert will not look at the System.Windows.Forms.Cursor at all. You will need to interface with the Windows User32.dll to send the appropriate messages to windows so it can route them appropriately to the other applications.
Here is some code to get you started looking in to sending messages via the User32 DLL in C#:
[DllImport("USER32.DLL")]
public static extern IntPtr FindWindow(string lpClassName,
string lpWindowName);
// Activate an application window.
[DllImport("USER32.DLL")]
public static extern bool SetForegroundWindow(IntPtr hWnd);
[DllImport("user32.dll")]
private static extern int SendMessage(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);
I hope this gets you started, but I don't have the time to go through each mouse message, what the wParam and lParam are, and what the Msg should be for each. I'm sure if you search around you can find the specific messages to send for each event such as mouse move, left click and right click.
Good luck.
Related
I'm a writing window management app in c# winforms to reposition other windows on the desktop. My issue came when I started using user32.dll calls to get the other windows size and position:
[DllImport("user32.dll")]
public static extern bool GetWindowRect(IntPtr hWnd, out Rect lpRect);
There's 2 problems with this method.
Most (but not all) windows the coordinates and size are off by 7 pixels (thanks dropshadow!), So for example a window at the left of the screen would be actually at -7 instead of 0.
Minimized windows are reporting -32000 coordinates.
To solve problem 2 I tried to use:
[DllImport("user32.dll")]
public static extern bool GetWindowPlacement(IntPtr hWnd, out WindowPlacement lpwndpl);
Using this method we can pull from the WindowPlacment struct the windows normal size when restored, even while it is minimized. Great! But it still gives the weird 7 pixel offset from the dropshadow... not so great.
In order to pull the actual size of the window (Problem 1) we can use:
[DllImport("dwmapi.dll")]
public static extern int DwmGetWindowAttribute(IntPtr hwnd, int dwAttribute, out Rect pvAttribute, int cbAttribute);
By getting the EXTENDED_FRAME_BOUNDS attribute we can pull the correct dimensions of the window without the drop shadow. But... if the window is minimized we still get coordinates in outer space!
And this is before even trying to solve the problem of scaled windows vs physical screen coordinates.
At the moment the only solution I can think of is to unminimize a window compare it's size with GetWindowRect to the GetWindowPlacement version and store the difference to take into account when moving and repositioning it. But to say this is a horrible workaround is an understatement.
Surely there's a better way?
I require the ability to get the height of the on screen keyboard for Windows 8.1, "TabTip.exe." So far I've managed to open and close it at will, but now I also need to get it's height so I can compensate for it in my app. I have TextBox controls near the very bottom of the Window that get covered up by the keyboard.
All attempts to utilize the Win API call "GetWindowRect" have failed.
Code placed just inside the beginning of the class definition:
private const string OnScreenKeyboardName = "TabTip";
DllImport("user32.dll")]
public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool GetWindowRect(HandleRef hWnd, ref RECT lpRect);
[StructLayout(LayoutKind.Sequential)]
public struct RECT
{
public int Left; // x position of upper-left corner
public int Top; // y position of upper-left corner
public int Right; // x position of lower-right corner
public int Bottom; // y position of lower-right corner
}
code placed inside one of the event handlers in the Window:
RECT rct = new RECT();
if (Process.GetProcessesByName(OnScreenKeyboardName).Length > 0)
{
Process[] Processes = Process.GetProcessesByName(OnScreenKeyboardName);
foreach (Process pOnScreenKeyboard in Processes)
{
if (!GetWindowRect(new HandleRef(this, pOnScreenKeyboard.Handle), ref rct))
{
MessageBox.Show("ERROR");
return;
}
MessageBox.Show(rct.ToString());
}
}
Consistent with most examples, I had originally been using a call to "FindWindow" to get the handle for the TabTip.exe Window. That seemed to work great for a while, but it stopped working all of a sudden within the last few days, and so I switched to "Process.FindByName..."
My test case involves placing the code (second part) above into the Window's "MouseMove" event handler. Then I make sure the on screen keyboard is showing, and then I move the mouse. This causes the event to fire and then it always shows the "ERROR" MessageBox, which indicates that "GetWindowRect" returns false (or has some kind of error?
I've spent a lot of time on Google searches, p/invoke, etc. This is frustrating because there seem to be very few examples of how to properly do this. And it seems there is some new thing called a HandleRef (am I using that properly? - there are basically no examples for that either!!!)
I really need to get this working. Can someone please tell me where I'm going wrong? Thanks!
You are passing the process handle (pOnScreenKeyboard.Handle) to GetWindowRect where GetWindowRect expects a window handle (HWND). Finding the process isn't sufficient - a process can create many windows, so you need to find the onscreen keyboard's window handle. You can try using pOnScreenKeyboard.MainWindowHandle, but from this post, you might find that it's null. You said you had a previous solution using FindWindow. I would go back to that and figure out why it stopped working.
In a C# Windows application there are 2 different mouse events, MouseEnter and MouseHover, which are both triggered when the cursor is over the object.
What is the difference between them?
Assuming you are in Windows Forms:
Mouse Enter occurs:
Occurs when the mouse pointer enters the control.
(MSDN)
Mouse Hover:
Occurs when the mouse pointer rests on the control.
A typical use of MouseHover is to display a tool tip when the mouse
pauses on a control within a specified area around the control (the
"hover rectangle"). The pause required for this event to be raised is
specified in milliseconds by the MouseHoverTime property.
(MSDN)
To set MouseHoverTime globally (not recommended, see #IronMan84's link here for a better solution), you can use the SystemParametersInfo function. Because thats a Win32 API call, you'll need PInvoke:
[DllImport("user32.dll", SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool SystemParametersInfo(SPI uiAction, uint uiParam, IntPtr pvParam, SPIF fWinIni);
Called as:
SystemParametersInfo(SPI.SPI_SETMOUSEHOVERTIME,
desiredHoverTimeInMs,
null,
SPIF.SPIF_SENDCHANGE );
Sigantures from PInvoke.NET: SystemParametersInfo, SPIF (Enum), SPI (Enum)
I didn't include the Enum signatures here because they are so freaking long. Just use the ones on PInvoke.Net (linked above)
For complete information on the SystemParametersInfo API call and its parameters, see MSDN.
MouseEnter is when your mouse just goes into the area.
MouseHover is when your mouse stays there for a bit (typically used for tooltips).
As far as mouse events go, the MouseEnter event occurs before any others. Also, you can manually set how long the mouse must hover over the area before the MouseHover event gets fired. You can see more about that here.
EDIT: I changed the link on adjusting MouseHoverTime. It turns that you can't easily do it, and that it is highly recommended not to, since it's a system value, which will affect all applications on the machine. Instead, the new link shows how to use a new, application-specific variable to do it manually.
I have a Windows store app that draws an image under the system's cursor. I capture all the cursor movements using:
var window = Window.Current .Content;
window .AddHandler(PointerMovedEvent, new PointerEventHandler (window_PointerMoved), true);
And this is working fine if I use my mouse to move the cursor.
However, I have another application - a desktop application -, that changes the position of the system's cursor. I'm using this method to set the position of the cursor programatically:
[DllImport("user32")]
private static extern int SetCursorPos(int x, int y);
However, when the cursor is moved programatically, the PointerMovedEvent on the store app does not fire!
Does anyone know how I can solve this problem?
I thought I could not use System.Runtime .InteropServices on Windows store apps, but it is allowed. Therefore, I've managed to achieve the desired behavior by having a thread that actively checks the cursor's current position using:
[ DllImport("user32.dll" )]
private static extern bool GetCursorPos(ref Win32Point pt);
It's not the most elegant solution, but it works!
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.