views:

76

answers:

1

I'm writing an application for a POS and using POS for .NET. I've found that when I call the WaitForDrawerClose method, while the application will sit and wait unresponsively until the drawer is closed (as desired), any clicks elsewhere seem to pile up in the queue and all fire once the drawer has been closed. How can I make my app stop listening for these events so long as WaitForDrawerClose has not yet returned? Thanks!

+1  A: 

You could avoid calling WaitForDrawerClose entirely, and handle the logic yourself.

Just listen for the OnDrawerStateChanged event instead to tell when the drawer is closed. Instead of synchronously blocking at that point (which is causing your problem), this would let you just exit your routine, update your UI (disable buttons to prevent events from firing, etc), and then re-enable everything cleanly when the drawer closes.

It's a bit more effort, since it's more work than a one line method, but it gives you a LOT more control over how your application will react if the user doesn't do what they're supposed to do. You even could have nag screens tell the user (after a certain delay) that they need to close the drawer, do more than the standard beeping, etc.

Reed Copsey
Thanks for your response, Reed. I think that makes sense, but admittedly this is forging into territory I'm unfamiliar with, and I'm not sure how I get access to that event. I presently have an instance of a CashDrawer object, but I can't get at the event because it's protected (right?).
Blumer
If this isn't one you're implementing, then you probably need to try to process your CashDrawer functions on a separate thread, for the same reason. Handling WaitForDrawerClose on your UI thread is what's causing this to "queue" events.
Reed Copsey
Yup, this is what I discovered shortly later--that since the WaitForDrawerClose was being called inside of the handling of the button click that caused the drawer to open, the handling of the event never finished. Thanks for your help.
Blumer