Scrolling

[rolisz]

Am I imagining things or scrolling by a certain fixed amount doesn't always move you the same distance?

I tried the following:

 robot.scroll_mouse_wheel('up', 10)

and 3 times out of 10 it would take me much further up than the rest of the time. Is this normal/known/expected?

I tried doing a for loop with sleep of 0.1 in it, and it seemed to be more predictable.

for _ in range(7):
    robot.scroll_mouse_wheel('down', 1)
    sleep(0.1)

[chriskiehl]

Lol. To be honest, I have no idea why the behavior is erratic. Despite writing the library, a lot of the functionality is voodoo to me ;)

I've run into several issues where a minimum delay is needed -- even if it's as small as .05 seconds. Maybe there's a MAX_SIZE type setting to whatever command queue Windows uses internally? Thus without giving it time to flush, it starts ignoring commands. I'm most likely completely wrong on that theory though -- just kind of brain storming out loud.

I looked through the mouse_event docs, but didn't see mention of anything relating to a maximum rate for commands. However, I did stumble upon a stackoverflow answer referencing the MSDN docs for sendkeys noting that it is susceptible to timing issues.

The SendKeys class is susceptible to timing issues, which some developers have had to work around. The updated implementation is still susceptible to timing issues, but is slightly faster and may require changes to the workarounds. The SendKeys class tries to use the previous implementation first, and if that fails, uses the new implementation. As a result, the SendKeys class may behave differently on different operating systems.

Again, I don't know the internals of mouse_evernt, but it may be some kind of internal scheduling that's getting messed up similar to what happens with sendkeys

Sorry I don't have a better answer, man! This was a weekend hack-it-together project for me. I'm not super familiar with the implementation of the Windows API.

Thanks for contributing to the project!

As a side note, your comment brought it to my attention that I had used string as the argument for the mouse direction. What do you think about implementing another class to take care of the constants for the function? e.g.

class Direction(object): 
    up = something 
    down = something_else   

It'll be a bit more convenient for those using code completion plugins, me thinks.

[rolisz]

Yes, I thought that probably Windows can't handle too many commands at once and it starts dropping them, but I wasn't sure. I never worked with the Windows API before.

Thanks for the library! It's very nice and super easy to use! Compared to Win32... it's awesome :)))

Regarding the direction argument, I don't that a class is necessary. In Python it's not really useful to have a class that only contains two things. You could either use some constants or maybe named tuples.

[gcq]

Didn't know about named tuples. That thing is amazing. I'm going to start using it like crazy.

[rolisz]

Python always has a nice surprise for everyone :)))

[chriskiehl]

I leave the implementation up to you ;) I'm fine with named tuples.

That said, I don't necessarily agree that a small class is inherently bad -- at least not in this case, as the class would be standing in for an enumerated type (which 2.x doesn't have), rather than simply being a code smelly data class.