Slinkx recursion

I've tracked down the source of my mysterious Send failures. It turns out it's possible for a VB timer tick event to occur in the middle of a Slinkx.Send. If your timer event handler tries to issue an IR command, then Send can be entered recursively, which it doesn't seem to like at all.

For some reason this seems to happen only in the compiled version of my app. When I run the same code from within the VB shell, the bug doesn't happen, i.e. the Sends never get interrupted by timer ticks. I'm using VB5 (VS 97 Pro), if that makes a difference.

My workaround for now is to disable all timers before calling Send, and re-enable them again afterward. I don't like this much because it messes up the timing, but I don't have a better idea.

A possibly related problem that I ran into a couple of weeks ago has to do with modal dialogs. If my SlinkeDeviceEvent handler raises a modal dialog, I get no further events from the Slinkx until the dialog is removed. This means that the user has to put down the remote and use the mouse to interact with the dialog, which kind of sucks. I tried putting a second Slinkx control on the dialog form, which works as long as the dialog is up. Unfortunately it has the side effect of putting the outer Slinkx into a comatose state from which the only recovery is to quit the app and start over.

My workaround for this was to do no actual processing of the device events from within the event handler; instead I just queue them into a buffer, and use a short-interval timer to dequeue and process them. This is what got me into trouble with the recursive Sends.