The way you determine if the event is from a distinct button from the last event is simply by its contents. For example, if a Girder user assigns a particular event to happen when the user presses the '1' button, the user will associate one of the codes received by the USB-UIRT when he/she presses the '1' button. Even if a couple different codes are emitted, as long as the codes are unique, one of these codes will trigger the event. Then, assigning another event to the '2' button works the same way.
Sure, but the same button is often sending the same code more than once, which is the issue here. The only way to avoid that triggering multiple events is to have some minimum time interval and ignore any events that come in within say 250ms to 500ms from the last one you triggered on. Otherwise, you'll trigger the same event multile times, which is a very bad thing when it kicks off a whole complex sequence of events.
I've now implemented that type of minimum time throttling, but it makes me a bit paranoid. The thing is, for my system, which is network distributed, it's not necessarily just a guy running a couple of HT components, who can see if the event did what it was supposed to do by just looking. In my system, such an event can kick off things all over the network, so I have to be very, very careful about this kind of thing, and it just worries me that there is not a more bullet proof means of insuring that one button invokes one event.
But, it's better to risk failing to cause an event if they press buttons too fast than to risk invoking the same event multiple times if they didn't mean to, so I'm using the minimum time thing, though even that will be a problem if they get fumble fingered and hold the button down too long.