SDK Version 2.10.3

In the next couple of days we will be pushing out the new version of the SDK. This is just a bug fix release. The old version 2.10.2 was eating keystrokes. Specifically, while it was waiting for slow operations like setting up the radio link between the base and the headset, it would prevent any WM_CHAR messages from being received by the application.

The root of this problem is the SDK's solution to another problem, what to do when an requested operation is going to be slow. Establishing the audio link between the headset and the base, for example, can take a second or two of handshaking on a good day and can take up to three before the connection attempt times out. The current solution is to not return until the operation is complete. This keeps things simple for the caller. If you set the AudioEnabled property to true, you can be confident that when you get control back, all of the SDK's operations will have finished.

Having an SDK operation block for as long as three seconds leads to a new problem though. If the function is in the caller's main UI thread, their application will become non-responsive until the SDK operation finishes. Having your app lock up for three seconds isn't acceptable. The reason it would lock up is because Windows messages wouldn't be getting processed. The solution we've taken in the SDK is to, instead of blocking completely, process those messages ourselves until the slow operation we are waiting for completes.

Processing the messages ourselves is a three step process that is almost completely handled by Windows. We simply receive the messages, do a little translation when necessary, and then send them where they need to go (this description involves some simplification). The message pump code looks like this:

while( ::PeekMessage(&msg, NULL, 0, 0, PM_REMOVE) )
{
   ::TranslateMessage(&msg);
   ::DispatchMessage(&msg);
}

At least the message pump code looks like that now.

It turns out that TranslateMessage() is mostly responsible for taking keyboard activity like WM_KEYDOWN and WM_KEYUP and generating the other relevant and useful messages like WM_CHAR. It also turns out that version 2.10.2 of the SDK was missing that line. And so, while waiting for long operations we were running our own message pump that wasn't creating WM_CHAR messages properly so any app that depends on those messages would appear to lose keystrokes while doing things like waiting for the audio link to come up. It's better now.

Knowing all of this, SDK users can do one of a few things.

• If you aren't depending on keyboard input during any long SDK operations you can do nothing.


• If the calls to the SDK aren't in your main UI thread you can do nothing.


• You can modify your application so that one of the above is true


• You can use the new SDK 2.10.3

Using the new SDK should be completely painless. The included 2.10.3 merge module is a drop in replacement for the old 2.10.2 one. Aside from the TranslateMessage() issue as discussed above, the functionality is identical and there shouldn't be any integration issues.