While I was dwelling on the fundamental interconnectedness of all
things on Tue, 15 Aug 2006 09:53:01 -0700, Tom Ogilvy
wrote:

if you can't code your conditions within the existing events, then I doubt
you can do it. I don't see any role for an API timer but then I don't know
what you actually want to accomplish.

why can't you call your routine from the appropriate event.

OK, I admit it; I still seek the holy grail of "on the fly validation"
- checking the data as the focus leaves the control, and (sometimes)
forcing the user to go back ahd "do it right this time". I actually
already have a good framework of classes to support this, and it
really works, except for one remaining problem.

Using the existing events causes a problem described by Stephen Bullen
back in 1998, which he seemed to have solved using Application.OnTime
Now, ...: if you don't let the series of events relating to a mouse
click finish before you start messing with the focus and control
states, Excel has a nasty habit of just saying "oh, no you don't!"
after the last event handler for those events, and undoing what you
did. The OnTime trick solved that by setting up an event which waits
for all the pending events to be handled before firing, except:

If you click quickly you can add more pending events before the
previous ones are all handled, and then the OnTime event waits for
_those_ events to be handled also. So, what I need is a way to
"wedge" an event of my own at the end of events which are currently
pending at one instant in time, so that any user actions after that
get queued to be handled _after_ my "special" event.

If I can do that, I've got it made.
--
Don Stauffer, Office Manager
Indiana Epilepsy and Child Neurology, Inc.