Posted by: tfabris
Moving the mouse is different than moving the mouse? What the heck? - 06/10/2011 21:37
I've got this really weird thing I'm running into in my software testing that I don't understand at all. I'm wondering if any of the Windows devs on the board have seen this?
Preface: I spend my day mostly testing how our software interacts with other software and hardware on the same system. In this particular case, I'm testing our software against the Verizon VZ Access Manager (VZAM) software. (VZAM is what's called a "connection manager", the app you use to connect your wireless card to the wireless carrier). One of our tests is to make sure that our software is reading correct and current data (such as the RSSI signal strength) from the Verizon wireless card plugged into the system, and that our data generally agrees with the data VZAM gets. Our software talks directly to the card, just like VZAM talks directly to the card.
So I've got automation that screen-scrapes VZAM and reads the RSSI values from it. Later, the idea is to compare those values to the values that our software has recorded, to make sure that we don't have a bug in the way that we're reading the card's data.
But here's the funny thing. On one particular XP system, VZAM sometimes goes "stale", reporting the same RSSI value over and over again forever. If you know anything about wireless, you'll know that the signal strength constantly fluctuates, even for a device that's standing still. So a "stuck" RSSI is an indication that something's not functioning as expected, and is flagged for closer investigation.
I've discovered that, on that system, when VZAM is stuck in this state, if I move the mouse or use any keystrokes of any kind, then VZAM suddenly starts getting varying RSSI data again as expected.
Aha, so I says to myself. I simply need to edit my automation tool to do some mouse moves and keystrokes to get VZAM to refresh properly.
But here's the weird part!! I can write a program that does automated MouseMoves and clicks and keystrokes like crazy, and VZAM still stays stuck, as if I had never moved the mouse. I can sit there and watch my automation minimize and restore VZAM, watch the mouse pointer move to the corners of the application, and even watch the mouse pointer hover over the signal strength indicator to get a balloon pop-up showing me the raw RSSI values (which are still stuck at the same value). I can watch it do all of those things, over and over again for hours, no change.
And then, at any time, all I have to do is give the mouse, the physical mouse itself, the slightest little move, and bam, suddenly VZAM wakes up like a kid on Christmas morning and starts giving me fresh data. Same thing with a keystroke: I can press the exact same keys that my automation was already clearly doing with SendKeys commands. As soon as I physically press a key, suddenly everything works.
In other words, I have a program that responds differently to actual physical input than it does to simulated input. How is that even possible?
Here's a concrete example. If VZAM is in this "stuck" state I described... If I press CTRL-K in VZAM, it opens up the diagnostics window where I can see the raw RSSI values. If I do this via the actual physical keyboard, VZAM becomes unstuck and gives me fresh values. If I do this via a piece of software automation with SendKeys, the diagnostics window still opens (so I know that VZAM got the keystroke) but the values are stale, stuck at the same values they've been for the last hour.
It's the weirdest thing. How is it that this can be possible? From the Windows operating system level, what's different about sending keystrokes and mouse movements to an application physically versus via automation? Anyone know?
Preface: I spend my day mostly testing how our software interacts with other software and hardware on the same system. In this particular case, I'm testing our software against the Verizon VZ Access Manager (VZAM) software. (VZAM is what's called a "connection manager", the app you use to connect your wireless card to the wireless carrier). One of our tests is to make sure that our software is reading correct and current data (such as the RSSI signal strength) from the Verizon wireless card plugged into the system, and that our data generally agrees with the data VZAM gets. Our software talks directly to the card, just like VZAM talks directly to the card.
So I've got automation that screen-scrapes VZAM and reads the RSSI values from it. Later, the idea is to compare those values to the values that our software has recorded, to make sure that we don't have a bug in the way that we're reading the card's data.
But here's the funny thing. On one particular XP system, VZAM sometimes goes "stale", reporting the same RSSI value over and over again forever. If you know anything about wireless, you'll know that the signal strength constantly fluctuates, even for a device that's standing still. So a "stuck" RSSI is an indication that something's not functioning as expected, and is flagged for closer investigation.
I've discovered that, on that system, when VZAM is stuck in this state, if I move the mouse or use any keystrokes of any kind, then VZAM suddenly starts getting varying RSSI data again as expected.
Aha, so I says to myself. I simply need to edit my automation tool to do some mouse moves and keystrokes to get VZAM to refresh properly.
But here's the weird part!! I can write a program that does automated MouseMoves and clicks and keystrokes like crazy, and VZAM still stays stuck, as if I had never moved the mouse. I can sit there and watch my automation minimize and restore VZAM, watch the mouse pointer move to the corners of the application, and even watch the mouse pointer hover over the signal strength indicator to get a balloon pop-up showing me the raw RSSI values (which are still stuck at the same value). I can watch it do all of those things, over and over again for hours, no change.
And then, at any time, all I have to do is give the mouse, the physical mouse itself, the slightest little move, and bam, suddenly VZAM wakes up like a kid on Christmas morning and starts giving me fresh data. Same thing with a keystroke: I can press the exact same keys that my automation was already clearly doing with SendKeys commands. As soon as I physically press a key, suddenly everything works.
In other words, I have a program that responds differently to actual physical input than it does to simulated input. How is that even possible?
Here's a concrete example. If VZAM is in this "stuck" state I described... If I press CTRL-K in VZAM, it opens up the diagnostics window where I can see the raw RSSI values. If I do this via the actual physical keyboard, VZAM becomes unstuck and gives me fresh values. If I do this via a piece of software automation with SendKeys, the diagnostics window still opens (so I know that VZAM got the keystroke) but the values are stale, stuck at the same values they've been for the last hour.
It's the weirdest thing. How is it that this can be possible? From the Windows operating system level, what's different about sending keystrokes and mouse movements to an application physically versus via automation? Anyone know?
