Last time, we saw that Get­Async­Key­State is not the way to detect whether the ESC key was down at the time the current input message was generated. But what about if we switched to Get­Key­State? Would that allow us to distinguish between an IDCANCEL caused by the ESC and an IDCANCEL that come from the Close button?

It helps, in that it tells you whether the ESC key was down when the event occurred, but just because the ESC is down doesn’t mean that the ESC key is why you got the message.

For example, suppose your policy is to simply ignore the ESC key, but to close the dialog if the user clicks the Close button. If the user holds the ESC key and clicks the Close button, the initial press of the ESC will generate an IDCANCEL, and your call to Get­Key­State will report that the ESC is down, so you will ignore the message.

And then the next IDCANCEL comes in due to the Close button, and your call to Get­Key­State will correctly report “The ESC key is still down.” So your function says, “Oh, this came from the ESC key, so ignore it.”

Except that it didn’t come from the ESC key. It came from the Close button. It just so happens that the ESC is down, but that’s not the reason why you got the second IDCANCEL.

Suppose you have a kiosk in a room with two entrances, a back entrance and a front entrance. If someone enters from the front door, you want to call the receptionist, but you don’t want to do it if they enter from the back door. What we’re doing by checking the ESC key is saying, “If the back door is open, then don’t call the receptionist.” But it’s possible that somebody is just standing in the back doorway, holding the door open, and during that time, somebody comes in the front door. Your logic sees that the back door is open and suppresses the call to the receptionist because you had assumed that only one door can be open at a time.

Next time, we’ll look at distinguishing ESC from Close.