Actually, we are clearing/verifying checks. The user is reading the amount from the check, hits enter and the check encoder takes it away. The encoder is the slow bottleneck and the way the MSComm control seems to work, it doesn't really alow the user to type ahead. So the current process is OK for a slow person, but you don't make money with slow people doing data entry. That is why I want to queue the data, let the printer print it as fast as it can (slowy) but not slow down the users. Then I need to give the users a visual that shows the check has been printed. that is where I wanted to use the event handler, when the check was printed, udpated the log. Now, I think I will do this with a second queue table that yet another timer is looking at and then updating the log. But I think that will be OK.

David