Re: Slinkx recursion

It's true that VB is single-threaded. But that doesn't mean events can't be nested. Any time a message loop is entered, new events can be issued, even if you're still inside an event handler. This has to be true or else modal dialogs couldn't work. The dialog has to be able to generate new events for its controls regardless of any outstanding event handlers higher up the call stack. (Remember, VB code consists of nothing but event handlers and their subroutines.)

Similarly, any non-Basic code (such as Send) called from within an event handler has the potential to generate nested events if it enters a message loop.

I can't offhand think of a control that permits nested events from the same control *instance*. Probably there aren't any. But certainly there are control *classes* that permit nested events from other controls of the same class. For instance, in the case of a timer tick event, you get no more ticks from that particular timer until you return from its event handler. But other timers are still free to fire in the meantime (provided you give them a chance by entering a message loop).

Similarly, if I put up a modal dialog in response to a button click, I don't expect to get any more click events from that button until the dialog comes down and the event handler returns. But buttons on the dialog obviously have to work in the meantime.

The only thing special about timers as far as I know is that they don't automatically get disabled when a modal dialog comes up. Buttons and other user-visible controls on an outer form get disabled -- i.e. they beep when you click on them -- but timers aren't clickable in the first place and so keep right on firing.

Experimentation shows that the Slinkx is like a timer in this respect. That is, it does not get disabled by a modal dialog but keeps right on issuing events -- so long as it's not the Slinkx event handler that put up the dialog in the first place. The difference is that multiple timers don't discombobulate each other, but multiple Slinkxs do. Your assumption that your Slinkx code doesn't run again until the handler returns is false; it *can* run again in response to a new event generated by another instance of Slinkx. I can send you some sample code to illustrate this if you like.

The problem with Send is not that I'm calling it from a timer event, but that the timer event can happen while still inside another Send. Presumably this is because Send contains a message loop. Suggestion: have Send return an error if it detects that it's being entered recursively.