Actions between user actions

I'm looking for a way to take actions the groups of events related to
a user action. For instance, if a TextBox is active and the user
clicks on a CommandButton, then on a ListBox, I want to take action
_after_ (not during) the last event related to the CommandButton
click, but _before_ the first event related to the ListBox click.
Using the handler for the last event from the first click or the first
event from the second click isn't what I'm looking for.

Using OnTime with Now and no offset looked promising until I realized
that if I do the two clicks quickly the subroutine set in the OnTime
doesn't get called until after the series of events related to the
second click. DoEvents doesn't seem to help with this situation at
all.

I'm considering looking into using an API timer, but I'm concerned it
may have the exact opposite problem, and run the subroutine before the
events resulting from the first click have all completed.

Any suggestions for what general direction to go are appreciated.
--
Don Stauffer, Office Manager
Indiana Epilepsy and Child Neurology, Inc.

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.

--
Regards,
Tom Ogilvy


"Indiana Epilepsy and Child Neurology" wrote:

> I'm looking for a way to take actions the groups of events related to
> a user action. For instance, if a TextBox is active and the user
> clicks on a CommandButton, then on a ListBox, I want to take action
> _after_ (not during) the last event related to the CommandButton
> click, but _before_ the first event related to the ListBox click.
> Using the handler for the last event from the first click or the first
> event from the second click isn't what I'm looking for.
>
> Using OnTime with Now and no offset looked promising until I realized
> that if I do the two clicks quickly the subroutine set in the OnTime
> doesn't get called until after the series of events related to the
> second click. DoEvents doesn't seem to help with this situation at
> all.
>
> I'm considering looking into using an API timer, but I'm concerned it
> may have the exact opposite problem, and run the subroutine before the
> events resulting from the first click have all completed.
>
> Any suggestions for what general direction to go are appreciated.
> --
> Don Stauffer, Office Manager
> Indiana Epilepsy and Child Neurology, Inc.
>

While I was dwelling on the fundamental interconnectedness of all
things on Tue, 15 Aug 2006 09:53:01 -0700, Tom Ogilvy
<[email protected]> 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.

I think I may have found a solution: disable the UserForm between
setting up the OnTime event and when it fires. User can't do
anything, so nothing to undo. If that means validation delays user
actions too much, I get a faster computer. IOW, force a single user
action and any validation associated with it to be "atomic" by making
the user wait until both are done.

Somebody noticed a while back that re-enabling the UserForm requires
..Enabled=True to be executed twice; has anyone found out why?

While I was dwelling on the fundamental interconnectedness of all
things on Tue, 15 Aug 2006 22:34:45 GMT, Indiana Epilepsy and Child
Neurology <[email protected]> wrote:

>While I was dwelling on the fundamental interconnectedness of all
>things on Tue, 15 Aug 2006 09:53:01 -0700, Tom Ogilvy
><[email protected]> 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.