Mouse "Cage" - How to keep a mouse on one half of

[Xzin]

Rather interesting problem I have here. 5 of the Zins are on 30" monitors. Until / if I shell out a ton for the models that support two independant inputs, I am running one WoW per screen. Since they are vertical (rotated 90 degrees), this is not a problem. I can use WoW Maximizer to force them to "full screen windowed" and yet remain in the top or bottom of the screen.

A - D are the active WoW screens. There are 6 monitors, mounted vertically - 3 on top 3 on the bottom. Above them (on A and C) is the desktop space. It works perfectly if the clients are all in the top left or lower right but then the density of the WoWs is lower than optimum. Flipping the monitor would work but then WoW would be upsidedown. You could rotate the entire desktop but then you are back at your original problem. So unless one could figure out a way to rotate WoW :) It seems like the mouse cage is an easier, faster, more reliable solution.

===========================
|...................|................... |..................|
|...................|................... |..................|
|-----------------------------------------------|
|...................|................... |..................|
|.........A........|....................|........C ........|
|...................|................... |..................|
|===========================
|...................|................... |..................|
|.........B........|.........X.........|........D. .......|
|...................|................... |..................|
| -----------------------------------------------|
|...................|................... |..................|
|...................|................... |..................|
==============================




Ok - but now the mice are no longer in sync. 2 are on the top and 2 are on the bottom.

My thoughts were either:

Write / find a program to "cage" the mouse, preventing it from leaving the respective WoW client area.

Run WoW "full screen windowed" (1600 x 2560) but move the play areas (2 up 2 down) such that it only renders 1600x1280 and leaves the rest black.

Any ideas on the first? I will be looking more into the second option shortly as I know they are out there for people who box on 2 monitors and don't want their character / main HUD in the middle of two screens.

With the second option, I would still have to "flip" the mouse on those screens though - such that moving up on those went down on the others - to keep the multicast mouse in sync.

It seems like the first option is easier and more reliable.

[Los]

Making a program that prevents your mouse to beyond certain pixels doesnt sound that bad to make, especially because you run them windowed.

[Xzin]

All it needs to do is have a hot key to release (turn on/off) and a boundary line, set by pixels or percentage (pixels preferred). It should simply act as a screen edge, but in the middle of the screen.

When it activates, it should move the mouse to the correct side.

I think that's it.

[shockbeta]

sending mouse clicks to two clients by "replicating" the mouse would be simple enough. Just a simple mousehook program. The trouble comes in when you want to mouselook around or click and drag. since you're trying to do the input on the same machine in two places... it could prove rather difficult. I've never actually wrote any program to do that so my knowledge is limited. As I said though if all the program was required to do was replicate mouse clicks in the respective space, it should be a simple program.

[Xesttub]

I'm not 100% sure what you're looking for, but I have code that sounded similar. http://xesttub.googlepages.com/MouseCage.rar Control the size of the box and the hotkey through mousecage.txt.

You might need uh VS2005 framework runtime dealie to run this? Also it won't use hotkeys if it doesn't have focus, but that program autohotkey? should be able to send keys to it I'd imagine.

[Xzin]

I don't need any keyboard interaction really. Just keep the mouse on the lower half of the scrren and thats it.

I hear what you are saying shock but it would be easier I would think to just prevent the mouse from moving down to the bottom rather than replicating it - mostly due to the added complexity and the mouselook needs to match, which it would automatically if they all have the same freq mouse attached - as long as the mouse was "resycned" such that the top left was caged and prevented from moving to the top of the actual monitor but instead stayed at the top of the game window (even though there was more desktop above it).

[shockbeta]

Think I misunderstood. I was going off our other discussion about replicating mouse to two instances on one screen. Where one was on top one was on bottom of the same screen. Getting ready to leave work so can't link to it, but if you're just wanting to send absolute mouse position to all monitors that are conected to seperate pc's then it would be a rather simple program. As far as capping where the mouse can go on the screen that is easy as well. if(pos.x >= ###) pos.x = ###; That will prevent it from going further hten what oyu want and keep it at the boundry. Anyways, I'm out the door so this was wrote fast and messy. I'll come back later when I have more time.

[Xzin]

Ahh ok - no problem. Yeah, all it really needs to do is cap the maximum amount of travel and be able to set where that is. Since the mouse is being multicast anyway, it just needs to in effect "flip" the mouse. It does so by preventing its movement as you indicated. I will review the code and compile the mousecage program suggested by Xesttub and see if that will work. If so then I think that is all that is needed. That or artifically trick the mouse/windows into thinking the real resolution is only 1600x1280 - but that starts to get messier and trickier. It would be nice if I could run WoW windowed but put up borders around it. That would be the "best" solution, but the mouse cage seems to be a close second.

[Xzin]

Ok, wow yeah - that was MUCH easier than I thought it to be. Thank you Xesttub!

[code:1]using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.IO;
using System.Runtime.InteropServices;

namespace MouseCage
{


public partial class Form1 : Form
{

public int Top = 100;
public int Bottom = 500;
public int Left = 100;
public int Right = 500;
String hotkey = "k";

public Form1()
{
InitializeComponent();
}

private void Form1_Load(object sender, EventArgs e)
{
try
{
FileStream file = new FileStream("mousecage.txt", FileMode.Open, FileAccess.Read);
StreamReader sr = new StreamReader(file);
string s = sr.ReadLine();
Top = Int16.Parse(s);
s = sr.ReadLine();
Bottom = Int16.Parse(s);
s = sr.ReadLine();
Left = Int16.Parse(s);
s = sr.ReadLine();
Right = Int16.Parse(s);
s = sr.ReadLine();
hotkey = s;

sr.Close();
file.Close();
}
catch
{
MessageBox.Show("mousecage.txt missing");
}

}


private void timer1_Tick(object sender, EventArgs e)
{
Point p = System.Windows.Forms.Cursor.Position;

if (System.Windows.Forms.Cursor.Position.Y <= Top)
p.Y = Top;
if (System.Windows.Forms.Cursor.Position.Y >= Bottom)
p.Y = Bottom;
if (System.Windows.Forms.Cursor.Position.X <= Left)
p.X = Left;
if (System.Windows.Forms.Cursor.Position.X >= Right)
p.X = Right;

System.Windows.Forms.Cursor.Position = p;
}

private void Form1_DoubleClick(object sender, EventArgs e)
{
timer1.Enabled = !timer1.Enabled;
}

private void Form1_KeyPress(object sender, KeyPressEventArgs e)
{
if (e.KeyChar.ToString() == hotkey)
timer1.Enabled = !timer1.Enabled;
}


}
}[/code:1]

[Xzin]

So the format of the .txt file is: Top,Bottom,Left,Right and then k is the escape character?

I assume that the k is the character to end the mouse lock (as set by the .txt file? and not EOF.

Pretty sure I will answer my own question when I compile it, but are the X and Y positions defined by the pixels or percentage? I assume pixels as the sample txt file has > 100 numbers. Pixels would be a more precise way anyway.

[Xesttub]

yeah top bottom left right and the "start/stop" key. For Starting/stopping the form needs focus, or you'd have to use autohotkey? to transmit it to that app without focus

the mouse will temporary move out of the range and then move back, so this might not work for you because of that minor desync? without your setup I can't really test it

[Xzin]

The "cage" needs to be a hard wall - like the edge of a monitor. As soon as I fire up VMware, I will test it and see how it performs.

I have no problems with needing to use autohotkey - the program will be able to have focus (although ideally, it should just move the mouse to some spot and then initialize with no dialog boxes or anything (perhaps a taskbar button?)

I will test the "bounciness" though and see if there is any. If so, it will desync the mice. If it acts as a hard edge then it should be perfect.

[Xzin]

Tested it on a clean XP install. Had to install .Net 3.0 to get it to run.

It works but the bounciness might screw things up. If it could be made to be a simple "WALL" instead - it would be perfect. Perhaps instead of recalculating the mouse position, it could redefine the border? It would only need to define one X coord border really to function.

[Xzin]

Would it be easier to modify WoW Maximizer?

http://wow-en.curse-gaming.com/downloads/details/146/

It is open source - all it needs to do is add a wall to one edge of the window. I just lack the experience to do it with only a few minutes of work.

[Xzin]

I went ahead and had this software written. It works very well. If anybody is interested in non-commercial use (not that its a complex program anyway) - PM me and let me know. Source is available.