The SendKeys *blog post* juice was definitely not worth the squeeze

by Michael S. Kaplan, published on 2007/09/10 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/09/10/4850360.aspx

It was over a year ago that I wrote a post about a Visual Basic language feature that has been around forever, and two specific problems with it (entitled Is the SendKeys juice worth the squeeze?) that intended to focus on two specific issues:

1. The way SendKeys combines the Windows WM_KEYDOWN and WM_CHAR notifications, a simplification that actually makes it harder to explain the concepts behind the two separate messages when people run into functionality problems with the combined functionality, and
2. The over-complicated implementation of SendKeys that used the low level functionality of journal hooks, a feature that requires permissions that users do not have by default, as a bonus making the method not work so well in Vista.

Both of these architectural moves were mistakes, in my opinion.

The first issue made up as much as 5% of my pre-Microsoft career consulting for folks to help fix up VB projects needing language support due to how much confusion it inevitably leads to.

And the second was a short-sightedly naive as opening up registry keys for read using a KEY_ALL_ACCESS request in the call to RegCreateKeyEx that works great on Windows 95 but dies on the vine when you run on an NT-based system and get introduced to security. I have some personal experience with that registry issue -- the Microsoft access wizards were riddled with that behavior, and in the world of least privilege with big corporations that did not give all their employees full access it was a deployment blocker of the first order.

Of course this was not communicated well, and you can see in the comments how one customer focused on the VB backcompat issue and the fact that all of their applications would be broken.

Luckily when the VB team stepped up with an updated version of the Visual Basic runtime DLL (msvbvm60.dll) that had a graceful fallback to a SendInput implementation, that was communicated as well, and the unhappy customer was able to be happy again (also for correcting me since I had apparently said it would not be fixed -- I had not; I just said that Windows wasn't gonna fix the problem, since it was a VB bug!).

Anyway, long time colleague and comrade Karl Peterson asked me whether the VB6 runtime "shim" could be done for msvbvm50.dll as well.

Of course the fix was not a shim, it was an updated binary. So I guess the answer is (strictly speaking) "NO" since it never was a shim, though the less literal answer to whether a VB5 runtime fix would also be forthcoming would be that "I don't know, since I don't know their plans here." When in doubt I would recommend asking someone like Paul Vick since he is much more likely to know stuff.

Though if I had to guess I'd look at the fact that according the DLL Hell database, the last update was done for products back in 1998 and every white paper I have seen goes out of its way to emphasize the 6 in its description of the supported, making me really unsure what the VB5 story is here. There has to be a reason, right?

Anyway, I did learn something from that old blog post about misunderstandings and how easy it was to have them happen and how unlike the world of sitcoms like Three's Company they were in the blog -- they simply aren't funny, and they are kind of distracting.

And the juice was not worth the squeeze, in any case....

This post brought to you by ၍ (U+104d, a.k.a. MYANMAR SYMBOL COMPLETED)

Yuhong Bao on 22 Apr 2009 9:47 PM:

Yuhong Bao on 22 Apr 2009 10:18 PM:

referenced by

go to newer or older post, or back to index or month or day