SDK Version 2.11.0
There is a new version of the SDK being wrapped up.
This version grew out of a similar issue as the one that gave rise to 2.10.3. That's right, message pumping is still causing problems. In this case, the problem was MFC's PreTranslateMessage(). PreTranslateMessage() is a good place to handle some messages. Particularly if you are looking for a consistent application-wide response to user input.
However, PreTranslateMessage() is a part of the MFC framework and the SDK has nothing to do with MFC. This leaves us in a bind. Having the SDK occasionally eat some keystrokes isn’t acceptable. Calling PreTranslateMessage() isn’t feasible. Leaving the messages in the queue means the UI locks up every time the radio link goes up. Finally, since this is a redistributable COM component, we have an obligation to maintain consistent behavior between versions as much as possible.
The solution we have chosen is to add a new interface, IDevice1, while leaving IDevice alone. By default, IDevice1 will work the same as IDevice. However, IDevice1 adds a property named AudioEnabledWait. Adjustments to the AudioEnabled property will no longer result in a delay when AudioEnabledWait is set to false (it is true be default). No waiting means the UI remains responsive without the need for message pumping. This leaves PreTranslateMessage() to run unfettered by any of our processing.
Implementing this new interface is painless. A quick change of name from IDevice to IDevice1 plus a call to set AudioEnabledWait is all that is needed. And, of course, for anyone who isn't experiencing any trouble there aren’t any changes needed.
While using the new interface is painless, it does result in some changes in behavior that you need to be aware of. For example, immediately after setting AudioEnabled to true, it may still read as false for several seconds. This is because, while the function return is instant, the RF link setup still takes as long as it always has. Similarly, the caller is responsible for not losing audio data by transmitting it prematurely.
Update (2-8-06): Well, wrapping things up took a bit longer than expected. However, the new version of the SDK is finally going out. While the delay was unfortunate, there were a number of behind the scenes process improvements which should make issuing future updates much easier and quicker.
This version grew out of a similar issue as the one that gave rise to 2.10.3. That's right, message pumping is still causing problems. In this case, the problem was MFC's PreTranslateMessage(). PreTranslateMessage() is a good place to handle some messages. Particularly if you are looking for a consistent application-wide response to user input.
However, PreTranslateMessage() is a part of the MFC framework and the SDK has nothing to do with MFC. This leaves us in a bind. Having the SDK occasionally eat some keystrokes isn’t acceptable. Calling PreTranslateMessage() isn’t feasible. Leaving the messages in the queue means the UI locks up every time the radio link goes up. Finally, since this is a redistributable COM component, we have an obligation to maintain consistent behavior between versions as much as possible.
The solution we have chosen is to add a new interface, IDevice1, while leaving IDevice alone. By default, IDevice1 will work the same as IDevice. However, IDevice1 adds a property named AudioEnabledWait. Adjustments to the AudioEnabled property will no longer result in a delay when AudioEnabledWait is set to false (it is true be default). No waiting means the UI remains responsive without the need for message pumping. This leaves PreTranslateMessage() to run unfettered by any of our processing.
Implementing this new interface is painless. A quick change of name from IDevice to IDevice1 plus a call to set AudioEnabledWait is all that is needed. And, of course, for anyone who isn't experiencing any trouble there aren’t any changes needed.
While using the new interface is painless, it does result in some changes in behavior that you need to be aware of. For example, immediately after setting AudioEnabled to true, it may still read as false for several seconds. This is because, while the function return is instant, the RF link setup still takes as long as it always has. Similarly, the caller is responsible for not losing audio data by transmitting it prematurely.
Update (2-8-06): Well, wrapping things up took a bit longer than expected. However, the new version of the SDK is finally going out. While the delay was unfortunate, there were a number of behind the scenes process improvements which should make issuing future updates much easier and quicker.
posted by aunomvo at 7:31 PM
0 Comments:
Post a Comment
<< Home