We use hotkeys for Buy-In, Add Player and New Player. The info read on the magnetic stripe is the player's ID number (numbers start at 1). As far as I know (for keystrokes) Tab is only used when in the New Player (edit player) dialogs to move from one text field to the next. The mouse is usually used to move around within TD ("OK" or "Cancel" buttons)
So, the swipe doesn't perform everything for you ... right? Meaning you (or some person) presses a key (Ctrl+A) or clicks the "Add Players" button to initiate a buy-in. Then, once the dialog opens (and the cursor is automatically in the "Find" field), you swipe the card and the card reader enters the card number for you. Then the person clicks the "Find" button, checks the checkbox next to the player's name, and clicks the "OK" button to buy the player in?
Some people have automated such that swiping a card (for example, with a card number of 123456789), would produce the keystrokes Ctrl+A, 123456789, Tab, Enter. This key sequence would open the Add Players dialog, enter the card number, and press the Find button. If the options "Buy-in players is enabled by default" and "Auto perform action" are enabled, swiping a card would either (a) buy the player into the tournament automatically, with no user intervention beyond swiping the card, or (b) leave the "Add Players to Tournament" dialog open in the case that the card number is not found. This is great, but sometimes the key sequences happen faster than humans can type, and that can lead to intermittent issues, because of the way dialogs in the TD app work, unless I code the dialog correctly.
See, most dialogs actually render with the basics first, and then a split second later add the player list. This allows the program to remain responsive on slower computers with larger player lists. Sometimes those player lists can take several seconds to come up, and if not done the way I described, it would take several seconds for a dialog to even appear after you pressed the hotkey or button to open the dialog. By splitting the rendering of the dialog, the dialog opens instantly, even on slower PCs, but the contents may take a second or 2 to appear. So the software remains more responsive even on slower PCs.
The issue is that in that split second keystrokes could be processed. If the OK button is pressed in that split second, the code will look through the checkboxes to see who has been selected, but at that time the player list isn't even on the dialog yet. And hence the error you are seeing. So determining how this is happening is rather crucial to fixing the problem (or at least determining what the problem is).
And now that I've typed all of that, I'm thinking this could be a different issue altogether. /sigh
And this actually brings up something I have had a few issues with. The dialog confirming the player movement after buying them in is set to OK by default. However, it has happened a handful of times (not often) where the clerk registering players clicked on cancel by mistake and the player was not seated. After a few more registrations, TD sat another player at the same seat as the original person (because the movement was cancelled). Can this dialog box be canned altogether? I found that it does actually slow down registration as well. If we forget to confirm and try to go to the next transaction by using a hotkey, nothing happens cause TD is still waiting to confirm and my staff is waiting for TD to print a receipt for the next player.
This is actually on my list of items to complete for the final 2.6 version: a preference to skip the auto-seat confirmation when buying players into the tournament. Out of curiosity, since there's no indication from the buy-in process of where a player is auto-seated (other than the dialog you want to can), how will you tell players where to sit? From the receipt or do you display the Seating Chart?