by Michael S. Kaplan, published on 2010/05/13 13:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/05/13/9993808.aspx
The other day the question came in from a tester around these parts:
We use the SetWindowsHookEx function to send keys to our IDE for testing purpose.
::SetWindowsHookEx(WH_JOURNALPLAYBACK, (HOOKPROC)PlayBack, GetModuleHandle(NULL), 0L);
However, on Win7 this returns the access denial error. I tried changing it to:
::SetWindowsHookEx(WH_JOURNALPLAYBACK, (HOOKPROC)PlayBack, NULL, ::GetCurrentThreadId());
Which get passed the access denial error but now it is returning the “This hook procedure can only be set globally” error.
Do you know of a way that can work around this problem?
Thanks!
Serious case of deja vu, let me tell you!
Does it look familiar to anyone?
No?
Ok, here are the hints: the old blogs that talk about another small incident involving the same issue:
Thankfully, the pointer to SendInput he got will resolve the issue of the tests that were failing.
I guess this means their product wasn't being run on Vista (which is when this problem started).
But I was thinking more about from a test perspective how much better the "new code" is even when the "old code" isn't failing.
I mean, since it is so much less invasive!
I've often been very happy with how large organizations will have shared libraries to do a lot of the basic work like mimicking the user's use of a keyboard, since having everyone solve those problems over and over again isn't a productive use of time -- since the job of the majority of the testers is not to test the input method itself but instead to test something else.
Isn't that a general principle in test -- to be minimally invasive in order to minimize the risk of the test itself having side effects that might taint the results to which stuff is input?
This applies to the VB <= 6.0 case as well, though not as much as to the case of actual tests of software products (presumably features are going to tested so if there are side effects of the way a featur works this hopefully comes out before the feature ships).
But there is another principle that I think would apply here - isn't it the job of tests to do the best possible job to simulate what the user is doing?
The kind of lesson you learn from being at the wrong level in the opposite direction, which can lead to other problems that also fail to adequately do the work. This is what leads to problems like Raymond mentions in You can't simulate keyboard input with PostMessage, for example.
I want to assume there is a principle like this, but I don't know since I'm not a tester.
These principles aren't borne out of laziness (even though the results may be the same in the end); they are borne out of a desire to do the job right (a successful test relying on WM_CHAR/PostMessage should not make one confident they have tested the feature since they can easily miss bugs that others could find in minutes by using a technique that better simulates user input -- like typing something!) and a desire for no blocking side effects (journal playback hooks have security requirements that non-elevated users don't have)....
Now the VB6 case doesn't follow the same rules about needing to mimic the input stream exactly (since they do not promise to do so, really), but the risk involved with pulling out grenade launchers to deter jaywalkers is something most developers can get their heads around. :-)
It just makes sense to do the least you possibly can to achieve the goal -- this minimizes the risk that the code trying to something will adversely affect what it is trying to do!
I mean, unless one is paid by the hour and must prove one is busy even if one is not usefully productive. In that case, one is I suppose free to do everything incorrectly in a bloated and hard to maintain way, in order to better support the later maintenance so very likely to be needed....