Olivier wrote:Hello, first a big thank you for your work!I have a small issue that I'd like to raise, as I didn't have it in previous version:I use the trackpad as right handed, and any usb connected mice as left handed.Since last version, during the initial detection, I noticed that my trackpad is not not detected anymore as first mouse. I just noticed that only my Pointing stick (in the middle of the keyboard is). Every other usb connected mice is well recognized. As a consequence, if I want to use the trackpad as right handed, I need to slightly touch the Pointing stick so that EitherMouse detects that I moved to the keyboard, and switches the buttons to right handed. If I don't touch the Pointing stick, it doesn't detect any touch on the Track pad.Interestingly, it was working fine on previous version 0.67 or 0.69 I believe.So no drama for me. I still use happily your tool. I just touch the Pointing stick briefly before moving to the Trackpad.CheersOlivier

HelloI just upgraded to 0.743 and I believe that this issue is back would you be able to re-introduce the fix?Thank you so much!CheersOlivier

[quote="Olivier"]Hello, first a big thank you for your work!I have a small issue that I'd like to raise, as I didn't have it in previous version:I use the trackpad as right handed, and any usb connected mice as left handed.Since last version, during the initial detection, I noticed that my trackpad is not not detected anymore as first mouse. I just noticed that only my Pointing stick (in the middle of the keyboard is). Every other usb connected mice is well recognized. As a consequence, if I want to use the trackpad as right handed, I need to slightly touch the Pointing stick so that EitherMouse detects that I moved to the keyboard, and switches the buttons to right handed. If I don't touch the Pointing stick, it doesn't detect any touch on the Track pad.Interestingly, it was working fine on previous version 0.67 or 0.69 I believe.So no drama for me. I still use happily your tool. I just touch the Pointing stick briefly before moving to the Trackpad.CheersOlivier[/quote]

HelloI just upgraded to 0.743 and I believe that this issue is back ;)would you be able to re-introduce the fix?Thank you so much!CheersOlivier

the little bug you're seeing is the reason this method doesn't work for keyboards, and sometimes acts up with mice when clicking/button pressing as the first action on a mouse change... EitherMouse kinda banks on the fact that you usually move a mouse before clicking/scrolling with it, in which case the mouse assignment changes and the button remapping occurs. When the first action on a new mouse is a click/button press, the change happens in reaction to that action, therefore acting like the previous mouse for the first input. This "problem" is exacerbated by the fact that your reversed scroll action is now coming in as a Send command, therefore its from a "zero device" discussed above, which is now being ignored in Beta 0.742... so the swap never happens until another action on the mouse is used.

One thing you should google/try is "FlipFlopWheel" and "FlipFlopHScroll" registry settings of the HID devices (and uncheck the EitherMouse reverse scroll options for testing), might make the EitherMouse option pointless

As for slowing down zooming, setting the scroll speed to 1 doesn't help? you might have to get creative, like have the WheelUp/Dn hotkey do Ctrl+[+]/[-] or something instead to get more control... This is probably outside of the scope of EitherMouse, but could be written as a plugin if needed.

great, thanks

the little bug you're seeing is the reason this method doesn't work for keyboards, and sometimes acts up with mice when clicking/button pressing as the first action on a mouse change... EitherMouse kinda banks on the fact that you usually move a mouse before clicking/scrolling with it, in which case the mouse assignment changes and the button remapping occurs. When the first action on a new mouse is a click/button press, the change happens in reaction to that action, therefore acting like the previous mouse for the first input. This "problem" is exacerbated by the fact that your reversed scroll action is now coming in as a Send command, therefore its from a "zero device" discussed above, which is now being ignored in Beta 0.742... so the swap never happens until another action on the mouse is used.

One thing you should google/try is "FlipFlopWheel" and "FlipFlopHScroll" registry settings of the HID devices (and uncheck the EitherMouse reverse scroll options for testing), might make the EitherMouse option pointless

As for slowing down zooming, setting the scroll speed to 1 doesn't help? you might have to get creative, like have the WheelUp/Dn hotkey do Ctrl+[+]/[-] or something instead to get more control... This is probably outside of the scope of EitherMouse, but could be written as a plugin if needed.

I'd like to similarly localize key remappings to specific keyboards. Is there an analogous AHK app for that?

Btw, I noticed one strange thing that is not very important (since it will rarely occur) but maybe it is worth mention since knowledge of it might help when debugging some more complex problem. One of my touchpads (Logitech T650) seems to temporarily inherit a reversed scroll setting when the last-used touchpad had it set. More precisely if the prior mouse event was from a touchpad with reversed V/H scroll enabled, and the first operation on the (nonreversed) T650 is an H/V scroll, then it will (wrongly) be reversed, and will remain that way till some non-scroll operation is performed on the T650, after which it correctly performs non-reversed scrolling (as configured). So, e.g. simply moving the pointer slightly before scrolling worksaround the bug. This weirdness only happens on the T650, not on my other nonreversed touchpads. Strange, eh?

gwarble wrote: Thinking about it a little, i think if the scroll "speed" was set to 1 line, but then AHK could send multiple Send ^{WheelUp} commands to speed up the zooming... Might be too many variables for EitherMouse but I'll add it to my do to list

In my case I need to slow-down zooming in order to comfortably perform single-step zoom changes (e.g. slightly zooming a web page).

[quote="gwarble"][...] Try Beta 0.742:https://www.eithermouse.com/Beta/EitherMouse%20Setup.exe [/quote]That did the trick. Now all works well. Thanks very much.

I'd like to similarly localize key remappings to specific keyboards. Is there an analogous AHK app for that?

Btw, I noticed one strange thing that is not very important (since it will rarely occur) but maybe it is worth mention since knowledge of it might help when debugging some more complex problem. One of my touchpads (Logitech T650) seems to temporarily inherit a reversed scroll setting when the last-used touchpad had it set. More precisely if the prior mouse event was from a touchpad with reversed V/H scroll enabled, and the first operation on the (nonreversed) T650 is an H/V scroll, then it will (wrongly) be reversed, and will remain that way till some non-scroll operation is performed on the T650, after which it correctly performs non-reversed scrolling (as configured). So, e.g. simply moving the pointer slightly before scrolling worksaround the bug. This weirdness only happens on the T650, not on my other nonreversed touchpads. Strange, eh?

[quote="gwarble"] Thinking about it a little, i think if the scroll "speed" was set to 1 line, but then AHK could send multiple Send ^{WheelUp} commands to speed up the zooming... Might be too many variables for EitherMouse but I'll add it to my do to list [/quote]In my case I need to [i]slow-down[/i] zooming in order to comfortably perform single-step zoom changes (e.g. slightly zooming a web page).

Unfortunately that fix doesn't work. Ctrl-VScroll does nothing on all mice with reversed VScroll enabled

Fixed i think

One strange thing that initially had me confused after the upgrade was that every mouse now appeared to have "reverse horizontal scroll" enabled (i.e. it's checked), but this was not actually true, i.e. the state of the display did not match internal state for that parameter.

Side effect of being kludged in quickly the other night, I think its fixed now

Speaking of parameters, how does the software default the parameters when it encounters a new mouse? Are there global defaults, or do they inherit from the last mouse? For default values, it probably makes sense to keep the horizontal and vertical reverse values in sync, i.e. both reversed or not, since it is probably rare for one to need them in opposite states.

I've waffled around on most of the settings over the years, but I think right now when a new mouse is detected, all current settings are applied to the new mouse... but I've tried where some default to the without-eithermouse default (ie not swapped in most cases...) I'll have to look

One thing I noticed while testing many different touchpads is that sometimes if you configure the optimal scroll speed then that speed is too fast to obtain comfortable single-step zoom changes. Is there an easy way to workaround that? Perhaps a damping factor for zoom speed, or a completely separate speed control?

Not that I know of, the scroll setting is a "number of lines" setting, so i would imagine 1 would be the most precise, but possibly too slow for some scrolling (in which case it could be sped up in some applications)

Edit: thinking about it a little, i think if the scroll "speed" was set to 1 line, but then AHK could send multiple Send ^{WheelUp} commands to speed up the zooming... Might be too many variables for EitherMouse but I'll add it to my do to list

[quote="gauss163"]Great, we're half way there. Now reversing H/V Scroll works correctly in the 0.741 beta. Kudos![/quote]Great...

[quote]Unfortunately that fix doesn't work. Ctrl-VScroll does nothing on all mice with reversed VScroll enabled[/quote]Fixed i think

[quote]One strange thing that initially had me confused after the upgrade was that every mouse now [i]appeared [/i]to have "reverse horizontal scroll" enabled (i.e. it's checked), but this was not actually true, i.e. the state of the display did not match internal state for that parameter.[/quote]Side effect of being kludged in quickly the other night, I think its fixed now

[quote]Speaking of parameters, how does the software default the parameters when it encounters a new mouse? Are there global defaults, or do they inherit from the last mouse? For default values, it probably makes sense to keep the horizontal and vertical reverse values in sync, i.e. both reversed or not, since it is probably rare for one to need them in opposite states.[/quote]I've waffled around on most of the settings over the years, but I think right now when a new mouse is detected, all current settings are applied to the new mouse... but I've tried where some default to the without-eithermouse default (ie not swapped in most cases...) I'll have to look

[quote]One thing I noticed while testing many different touchpads is that sometimes if you configure the optimal scroll speed then that speed is too fast to obtain comfortable [i]single-step[/i] zoom changes. Is there an easy way to workaround that? Perhaps a damping factor for zoom speed, or a completely separate speed control? [/quote]Not that I know of, the scroll setting is a "number of lines" setting, so i would imagine 1 would be the most precise, but possibly too slow for some scrolling (in which case it could be sped up in some applications)

Edit: thinking about it a little, i think if the scroll "speed" was set to 1 line, but then AHK could send multiple [c]Send ^{WheelUp}[/c] commands to speed up the zooming... Might be too many variables for EitherMouse but I'll add it to my do to list

gwarble wrote:Ok I see what the problem is... now I need to figure out a workaround... By enabling what I call a "zero device", some hardware and most software mouse input is detected via RawInput as a device with handle "0" and device name is an empty string... I allow the device because some users have hardware that appears like this (probably a driver/software thing) but when reversing scroll wheel it is creating a hotkey, which is then detected as a zero device as well...

Great, we're half way there. Now reversing H/V Scroll works correctly in the 0.741 beta. Kudos!

gwarble wrote:the zoom/ctrl-scroll option is an easy fix at least

Unfortunately that fix doesn't work. Ctrl-VScroll does nothing on all mice with reversed VScroll enabled (but works fine on non-reversed mice). in 0.69 Zoom did work (but had the wrong direction) on reversed mice.

One strange thing that initially had me confused after the upgrade was that every mouse now appeared to have "reverse horizontal scroll" enabled (i.e. it's checked), but this was not actually true, i.e. the state of the display did not match internal state for that parameter.

Speaking of parameters, how does the software default the parameters when it encounters a new mouse? Are there global defaults, or do they inherit from the last mouse? For default values, it probably makes sense to keep the horizontal and vertical reverse values in sync, i.e. both reversed or not, since it is probably rare for one to need them in opposite states.

One thing I noticed while testing many different touchpads is that sometimes if you configure the optimal scroll speed then that speed is too fast to obtain comfortable single-step zoom changes. Is there an easy way to workaround that? Perhaps a damping factor for zoom speed, or a completely separate speed control?

gwarble wrote:if you're talking about a third scrolling axis on a mouse I don't know how to detect that (nor have I ever seen one, but i imagine it could exist)

Nope, only Flatland (horizontal, vertical and zoom scrolling).

[quote="gwarble"]Ok I see what the problem is... now I need to figure out a workaround... By enabling what I call a "zero device", some hardware and most software mouse input is detected via RawInput as a device with handle "0" and device name is an empty string... I allow the device because some users have hardware that appears like this (probably a driver/software thing) but when reversing scroll wheel it is creating a hotkey, which is then detected as a zero device as well...[/quote]Great, we're half way there. Now reversing H/V Scroll works correctly in the 0.741 beta. Kudos!

[quote="gwarble"]the zoom/ctrl-scroll option is an easy fix at least[/quote]Unfortunately that fix doesn't work. Ctrl-VScroll does nothing on all mice with reversed VScroll enabled (but works fine on non-reversed mice). in 0.69 Zoom did work (but had the wrong direction) on reversed mice.

One strange thing that initially had me confused after the upgrade was that every mouse now [i]appeared [/i]to have "reverse horizontal scroll" enabled (i.e. it's checked), but this was not actually true, i.e. the state of the display did not match internal state for that parameter.

Speaking of parameters, how does the software default the parameters when it encounters a new mouse? Are there global defaults, or do they inherit from the last mouse? For default values, it probably makes sense to keep the horizontal and vertical reverse values in sync, i.e. both reversed or not, since it is probably rare for one to need them in opposite states.

One thing I noticed while testing many different touchpads is that sometimes if you configure the optimal scroll speed then that speed is too fast to obtain comfortable [i]single-step[/i] zoom changes. Is there an easy way to workaround that? Perhaps a damping factor for zoom speed, or a completely separate speed control?

[quote="gwarble"]if you're talking about a third scrolling axis on a mouse I don't know how to detect that (nor have I ever seen one, but i imagine it could exist)[/quote]Nope, only Flatland (horizontal, vertical and zoom scrolling).

Yeah i need to make that an option... Some people need the zero device as a seperate device because of hardware, some get issues with a zero device because of software input (ie your case, or hotkeys, etc)... I can't think of a setup that will work for everyone, so i'll be adding in a "allow zero device" option when i can.

Thanks

Yeah i need to make that an option... Some people need the zero device as a seperate device because of hardware, some get issues with a zero device because of software input (ie your case, or hotkeys, etc)... I can't think of a setup that will work for everyone, so i'll be adding in a "allow zero device" option when i can.

Disabling zero device detection fixed something I was going to ask about. In v0.69 and prior, AHK's "Click" command used the current mouse settings, and when I upgraded to v0.73 the Click command would register as a separate mouse in EitherMouse. My script would Click, the mouse would change in EitherMouse, and that first input would get dropped. v0.74 same thing. v0.741 is back to the old functionality and my AHK Clicks are clicking again, so it looks like it was the zero device detection.

Disabling zero device detection fixed something I was going to ask about. In v0.69 and prior, AHK's "Click" command used the current mouse settings, and when I upgraded to v0.73 the Click command would register as a separate mouse in EitherMouse. My script would Click, the mouse would change in EitherMouse, and that first input would get dropped. v0.74 same thing. v0.741 is back to the old functionality and my AHK Clicks are clicking again, so it looks like it was the zero device detection.

Ok I see what the problem is... now I need to figure out a workaround... By enabling what I call a "zero device", some hardware and most software mouse input is detected via RawInput as a device with handle "0" and device name is an empty string... I allow the device because some users have hardware that appears like this (probably a driver/software thing) but when reversing scroll wheel it is creating a hotkey, which is then detected as a zero device as well...

So I will finally have to make an option to enable or disable the zero device, or figure out some other workaround so that reverse scrolling doesn't trigger a mouse change, have to think on this one.

the zoom/ctrl-scroll option is an easy fix at least

Edit:ok, try the Beta version 0.741:https://www.eithermouse.com/Beta/Either ... 0Setup.exei kludged in a reverse horizontal scroll option, and removed the zero device detection, which should solve your scrolling issues... and allowed modifiers on the scrolling hotkeys, so zoom should work... if you're talking about a third scrolling axis on a mouse I don't know how to detect that (nor have I ever seen one, but i imagine it could exist)

Ok I see what the problem is... now I need to figure out a workaround... By enabling what I call a "zero device", some hardware and most software mouse input is detected via RawInput as a device with handle "0" and device name is an empty string... I allow the device because some users have hardware that appears like this (probably a driver/software thing) but when reversing scroll wheel it is creating a hotkey, which is then detected as a zero device as well...

So I will finally have to make an option to enable or disable the zero device, or figure out some other workaround so that reverse scrolling doesn't trigger a mouse change, have to think on this one.

the zoom/ctrl-scroll option is an easy fix at least

Edit:ok, try the Beta version 0.741:https://www.eithermouse.com/Beta/EitherMouse%20Setup.exei kludged in a reverse horizontal scroll option, and removed the zero device detection, which should solve your scrolling issues... and allowed modifiers on the scrolling hotkeys, so zoom should work... if you're talking about a third scrolling axis on a mouse I don't know how to detect that (nor have I ever seen one, but i imagine it could exist)

gauss163 wrote:Joel: I did manage to find a copy of version 0.69 in my downloads folder.

Ok cool, I also linked directly to 0.69 above

Once I downgraded to 0.69 the weird scroll problems caused by "reverse scroll direction" disappeared. Maybe it's worth emphasizing that I am in the process of testing many different touchpads, so it might be possible that the large number of different settings could cause problems (I was up to Mouse34 at one point). But 0.69 handled it all well - kudos! I have no idea why the latest version is messing up when reversing the scroll direction (and also crashing in the Tooltip), but I'll be happy to help debug.

Very cool, I've never had the mouse count up that high. I'm glad to hear downgrading fixed the issue, so I have somewhere to hunt for the bug (i didn't think I even changed anything with that option, but I must have). I can also imagine the errors you got with so many mice with ToolTips on because it uses the mouse number as the ToolTip number, but AHK's use of ToolTip maxes out at 20! I'll have to put in a fix for that.

Btw, I noticed also that reverse scroll direction does not reverse the direction of Zooming (Ctrl+VScroll). Having horizontal and/or Zoom scroll directions inconsistent with (reversed) vertical Scroll direction is problematic (showstopper for me). The goal is to have a consistent UI model: scrolling should function one of two ways: as if grabbing the page and moving it (as on a phone), or, opposite-direction-wise, as if grabbing the scroll-bars and moving them (but not some mixture of the two). Reversing the scroll direction should switch between these two scroll models (for both H/V directions + Zoom). Probably that works for most uses (but some advanced apps might require independent reversal controls on H/V/Z scroll). I'll by happy to help with testing and/or code writing to remedy this.

Yeah that's also not handled, I will put it on my to do list, thanks. I will let you know when I have an update ready and you can do some testing for me, thanks

What do I need to do (if anything) to preserve settings when down/upgrading?

Nothing, except make sure to not check the "clean install" option when installing, then it should use the existing settings.

Thanks again,- Joel

[quote="gauss163"]Joel: I did manage to find a copy of version 0.69 in my downloads folder.[/quote]

Ok cool, I also linked directly to 0.69 above

[quote]Once I downgraded to 0.69 the weird scroll problems caused by "reverse scroll direction" disappeared. Maybe it's worth emphasizing that I am in the process of testing [i]many[/i] different touchpads, so it might be possible that the large number of different settings could cause problems (I was up to Mouse34 at one point). But 0.69 handled it all well - kudos! I have no idea why the latest version is messing up when reversing the scroll direction (and also crashing in the Tooltip), but I'll be happy to help debug.[/quote]

Very cool, I've never had the mouse count up that high. I'm glad to hear downgrading fixed the issue, so I have somewhere to hunt for the bug (i didn't think I even changed anything with that option, but I must have). I can also imagine the errors you got with so many mice with ToolTips on because it uses the mouse number as the ToolTip number, but AHK's use of ToolTip maxes out at 20! I'll have to put in a fix for that.

[quote]Btw, I noticed also that reverse scroll direction does not reverse the direction of Zooming (Ctrl+VScroll). Having horizontal and/or Zoom scroll directions inconsistent with (reversed) vertical Scroll direction is problematic (showstopper for me). The goal is to have a consistent UI model: scrolling should function one of two ways: as if grabbing the page and moving it (as on a phone), or, opposite-direction-wise, as if grabbing the scroll-bars and moving them (but not some mixture of the two). Reversing the scroll direction should switch between these two scroll models (for both H/V directions + Zoom). Probably that works for most uses (but some advanced apps might require [i]independent[/i] reversal controls on H/V/Z scroll). I'll by happy to help with testing and/or code writing to remedy this.[/quote]

Yeah that's also not handled, I will put it on my to do list, thanks. I will let you know when I have an update ready and you can do some testing for me, thanks :)

[quote]What do I need to do (if anything) to preserve settings when down/upgrading?[/quote]

Nothing, except make sure to not check the "clean install" option when installing, then it should use the existing settings.

Joel: I did manage to find a copy of version 0.69 in my downloads folder. Once I downgraded to 0.69 the weird scroll problems caused by "reverse scroll direction" disappeared. Maybe it's worth emphasizing that I am in the process of testing many different touchpads, so it might be possible that the large number of different settings could cause problems (I was up to Mouse34 at one point). But 0.69 handled it all well - kudos! I have no idea why the latest version is messing up when reversing the scroll direction (and also crashing in the Tooltip), but I'll be happy to help debug.

Btw, I noticed also that reverse scroll direction does not reverse the direction of Zooming (Ctrl+VScroll). Having horizontal and/or Zoom scroll directions inconsistent with (reversed) vertical Scroll direction is problematic (showstopper for me). The goal is to have a consistent UI model: scrolling should function one of two ways: as if grabbing the page and moving it (as on a phone), or, opposite-direction-wise, as if grabbing the scroll-bars and moving them (but not some mixture of the two). Reversing the scroll direction should switch between these two scroll models (for both H/V directions + Zoom). Probably that works for most uses (but some advanced apps might require independent reversal controls on H/V/Z scroll). I'll by happy to help with testing and/or code writing to remedy this.

What do I need to do (if anything) to preserve settings when down/upgrading?

Joel: I did manage to find a copy of version 0.69 in my downloads folder. Once I downgraded to 0.69 the weird scroll problems caused by "reverse scroll direction" disappeared. Maybe it's worth emphasizing that I am in the process of testing [i]many[/i] different touchpads, so it might be possible that the large number of different settings could cause problems (I was up to Mouse34 at one point). But 0.69 handled it all well - kudos! I have no idea why the latest version is messing up when reversing the scroll direction (and also crashing in the Tooltip), but I'll be happy to help debug.

Btw, I noticed also that reverse scroll direction does not reverse the direction of Zooming (Ctrl+VScroll). Having horizontal and/or Zoom scroll directions inconsistent with (reversed) vertical Scroll direction is problematic (showstopper for me). The goal is to have a consistent UI model: scrolling should function one of two ways: as if grabbing the page and moving it (as on a phone), or, opposite-direction-wise, as if grabbing the scroll-bars and moving them (but not some mixture of the two). Reversing the scroll direction should switch between these two scroll models (for both H/V directions + Zoom). Probably that works for most uses (but some advanced apps might require [i]independent[/i] reversal controls on H/V/Z scroll). I'll by happy to help with testing and/or code writing to remedy this.

What do I need to do (if anything) to preserve settings when down/upgrading?

Bill D wrote:I made the mistake of upgrading from 0.69 to 0.71 and now the reverse scrolling option is completely messed up on some of my touchpads. On some it does nothing, on others when checked it will inhibit scrolling in one direction (it appears to jittery "struggle" too, but won't). They all worked fine in 0.69.... Also in 0.71 I got the error: Max window number is 20. Line# 514: Tooltip... after exiting the Windows Mouse properties dialog (afer invoking it from EitherMouse). I don't know if this is related to the revere scrolling problem.

Thats the first I've heard of this issue, but i will look into the reverse scrolling issue and the tooltip error message issues... thanks

Does anyone know how I can downgrade back to version 0.69? I can't find it anywhere.

Also, does anyone know if EitherMouse can also reverse horizontal scrolling too?

Not currently, but I will add it to my to do list, should be possible.

thanks for the feedback, and if possible please report back and confirm that downgrading to 0.69 fixes your new issues...- joel

[quote="Bill D"]I made the mistake of upgrading from 0.69 to 0.71 and now the reverse scrolling option is completely messed up on some of my touchpads. On some it does nothing, on others when checked it will inhibit scrolling in one direction (it appears to jittery "struggle" too, but won't). They all worked fine in 0.69.... Also in 0.71 I got the error: Max window number is 20. Line# 514: Tooltip... after exiting the Windows Mouse properties dialog (afer invoking it from EitherMouse). I don't know if this is related to the revere scrolling problem.[/quote]

Thats the first I've heard of this issue, but i will look into the reverse scrolling issue and the tooltip error message issues... thanks

[quote]Does anyone know how I can downgrade back to version 0.69? I can't find it anywhere.[/quote]

https://www.eithermouse.com/EitherMouse%20Setup%200.69.exe

[quote]Also, does anyone know if EitherMouse can also reverse [i]horizontal [/i]scrolling too?[/quote]

Not currently, but I will add it to my to do list, should be possible.

thanks for the feedback, and if possible please report back and confirm that downgrading to 0.69 fixes your new issues...- joel

I made the mistake of upgrading from 0.69 to 0.71 and now the reverse scrolling option is completely messed up on some of my touchpads. On some it does nothing, on others when checked it will inhibit scrolling in one direction (it appears to jittery "struggle" too, but won't). They all worked fine in 0.69. Does anyone know how I can downgrade back to version 0.69? I can't find it anywhere.

Also in 0.71 I got the error: Max window number is 20. Line# 514: Tooltip... after exiting the Windows Mouse properties dialog (afer invoking it from EitherMouse). I don't know if this is related to the revere scrolling problem.

Also, does anyone know if EitherMouse can also reverse horizontal scrolling too?

I made the mistake of upgrading from 0.69 to 0.71 and now the reverse scrolling option is completely messed up on some of my touchpads. On some it does nothing, on others when checked it will inhibit scrolling in one direction (it appears to jittery "struggle" too, but won't). They all worked fine in 0.69. Does anyone know how I can downgrade back to version 0.69? I can't find it anywhere.

Also in 0.71 I got the error: Max window number is 20. Line# 514: Tooltip... after exiting the Windows Mouse properties dialog (afer invoking it from EitherMouse). I don't know if this is related to the revere scrolling problem.

Also, does anyone know if EitherMouse can also reverse [i]horizontal [/i]scrolling too?

gwarble, your domain isn't resolving. It appears the name servers for you site have pooped out. Can you check that?On a related note, do you have any download mirrors? Couldn't find any while trying to install EitherMouse on a new comp

gwarble, your domain isn't resolving. It appears the name servers for you site have pooped out. Can you check that?On a related note, do you have any download mirrors? Couldn't find any while trying to install EitherMouse on a new comp

Hello, first a big thank you for your work!I have a small issue that I'd like to raise, as I didn't have it in previous version:I use the trackpad as right handed, and any usb connected mice as left handed.Since last version, during the initial detection, I noticed that my trackpad is not not detected anymore as first mouse. I just noticed that only my Pointing stick (in the middle of the keyboard is). Every other usb connected mice is well recognized. As a consequence, if I want to use the trackpad as right handed, I need to slightly touch the Pointing stick so that EitherMouse detects that I moved to the keyboard, and switches the buttons to right handed. If I don't touch the Pointing stick, it doesn't detect any touch on the Track pad.Interestingly, it was working fine on previous version 0.67 or 0.69 I believe.So no drama for me. I still use happily your tool. I just touch the Pointing stick briefly before moving to the Trackpad.CheersOlivier

Hello, first a big thank you for your work!I have a small issue that I'd like to raise, as I didn't have it in previous version:I use the trackpad as right handed, and any usb connected mice as left handed.Since last version, during the initial detection, I noticed that my trackpad is not not detected anymore as first mouse. I just noticed that only my Pointing stick (in the middle of the keyboard is). Every other usb connected mice is well recognized. As a consequence, if I want to use the trackpad as right handed, I need to slightly touch the Pointing stick so that EitherMouse detects that I moved to the keyboard, and switches the buttons to right handed. If I don't touch the Pointing stick, it doesn't detect any touch on the Track pad.Interestingly, it was working fine on previous version 0.67 or 0.69 I believe.So no drama for me. I still use happily your tool. I just touch the Pointing stick briefly before moving to the Trackpad.CheersOlivier

oh, and for the source, check the "Include source code" checkbox in the installer and you will get EitherMouse.ahk in the installed directory. You can then edit the code and re-compile by running the .ahk (you must have ahk installed for this, but the resulting .exe will not be built from your current AutoHotkeySC.bin, but rather "recompiled" using the modified code but the original .exe

oh, and for the source, check the "Include source code" checkbox in the installer and you will get EitherMouse.ahk in the installed directory. You can then edit the code and re-compile by running the .ahk (you must have ahk installed for this, but the resulting .exe will not be built from your current AutoHotkeySC.bin, but rather "recompiled" using the modified code but the original .exe