Timer events that must occur

[Steve Jorgensen]

I've recently been playing with some UI ideas that require the user of a timer
to drive animation. The problem I'm having is that Access routinely stops
firing timer events for long periods of time.

For example, the user types a character in another window, and the timer
stops. The user types another key, and the timer starts again, runs for a few
seconds, then stops again.

Now, the code I'm writing would easily tolerate a few dropped timer event
firings, but these long pauses just don't work.

Of course, an ActiveX control might do the trick, but I also like to limit the
use of external controls because it makes the software harder to deploy,
especially for quick demos and such.

Does anyone have any clever solutions for this problem?

[Dimitri Furman]

On Apr 10 2005, 12:04 am, Steve Jorgensen <no****@nospam. nospam> wrote
in news:h2******** *************** *********@4ax.c om:

I've recently been playing with some UI ideas that require the user of
a timer to drive animation. The problem I'm having is that Access
routinely stops firing timer events for long periods of time.

For example, the user types a character in another window, and the
timer stops. The user types another key, and the timer starts again,
runs for a few seconds, then stops again.

Now, the code I'm writing would easily tolerate a few dropped timer
event firings, but these long pauses just don't work.

Of course, an ActiveX control might do the trick, but I also like to
limit the use of external controls because it makes the software
harder to deploy, especially for quick demos and such.

Does anyone have any clever solutions for this problem?

SetTimer API, perhaps? Needs a callback function, which shouldn't be a
problem in newer versions of Access.

--
remove a 9 to reply by email

[Steve Jorgensen]

On Sun, 10 Apr 2005 15:33:26 -0000, Dimitri Furman <df*****@cloud9 9.net>
wrote:

On Apr 10 2005, 12:04 am, Steve Jorgensen <no****@nospam. nospam> wrote
in news:h2******** *************** *********@4ax.c om:

I've recently been playing with some UI ideas that require the user of
a timer to drive animation. The problem I'm having is that Access
routinely stops firing timer events for long periods of time.

For example, the user types a character in another window, and the
timer stops. The user types another key, and the timer starts again,
runs for a few seconds, then stops again.

Now, the code I'm writing would easily tolerate a few dropped timer
event firings, but these long pauses just don't work.

Of course, an ActiveX control might do the trick, but I also like to
limit the use of external controls because it makes the software
harder to deploy, especially for quick demos and such.

Does anyone have any clever solutions for this problem?

SetTimer API, perhaps? Needs a callback function, which shouldn't be a
problem in newer versions of Access.

Shouldn't it? Wouldn't that amount to multi-threading, which VBA does not
support?

[Tom van Stiphout]

On Sat, 09 Apr 2005 21:04:27 -0700, Steve Jorgensen
<no****@nospam. nospam> wrote:

The way I understand timers, an ActiveX control (I'm thinking you are
planning on writing one) may not do the trick. WM_TIMER events are
used by the "normal" timers (SetTimer, the Timer control in VB and
Access) and they are low priority events, that only happen after all
other events are processed. They are also combined to a single event
if their time has expired before they got a change to tick.

The multimedia timer timeSetEvent ticks more predictably, but at the
price of consuming more CPU resources.

-Tom.

I've recently been playing with some UI ideas that require the user of a timer
to drive animation. The problem I'm having is that Access routinely stops
firing timer events for long periods of time.

For example, the user types a character in another window, and the timer
stops. The user types another key, and the timer starts again, runs for a few
seconds, then stops again.

Now, the code I'm writing would easily tolerate a few dropped timer event
firings, but these long pauses just don't work.

Of course, an ActiveX control might do the trick, but I also like to limit the
use of external controls because it makes the software harder to deploy,
especially for quick demos and such.

Does anyone have any clever solutions for this problem?

[Dimitri Furman]

On Apr 10 2005, 03:01 pm, Steve Jorgensen <no****@nospam. nospam> wrote
in news:5t******** *************** *********@4ax.c om:

SetTimer API, perhaps? Needs a callback function, which shouldn't be a
problem in newer versions of Access.

Shouldn't it? Wouldn't that amount to multi-threading, which VBA does
not support?

I see your point, but then AddressOf is a supported VBA operator, so it may
be worth a try...

--
remove a 9 to reply by email

[Steve Jorgensen]

On Mon, 11 Apr 2005 02:11:54 -0000, Dimitri Furman <df*****@cloud9 9.net>
wrote:

On Apr 10 2005, 03:01 pm, Steve Jorgensen <no****@nospam. nospam> wrote
in news:5t******** *************** *********@4ax.c om:

SetTimer API, perhaps? Needs a callback function, which shouldn't be a
problem in newer versions of Access.

Shouldn't it? Wouldn't that amount to multi-threading, which VBA does
not support?

I see your point, but then AddressOf is a supported VBA operator, so it may
be worth a try...

Well, AddressOf can be used in ways that can reasonably be predicted not to
have side effects (as long as your code has no bugs). Multi-threading of code
that does not support it can have unpredictable side effects at unpredictable
rates, so the fact that code appears to work in testing is no guarantee that
it's safe. I don't think I would do it.

An intriguing suggestion, though.

[Steve Jorgensen]

Actually, the low-priority nature of the timer wouldn't be a problem for my
code in and of itself. It's just the fact that timer events can go on
vacation for very long periods of time. I don't know if this is an Access
behavior or a WM_TIMER behavior, but I would be a bit surprised if WM_TIMER
acted that way.

On Sun, 10 Apr 2005 12:01:55 -0700, Tom van Stiphout <no************ *@cox.net>
wrote:

On Sat, 09 Apr 2005 21:04:27 -0700, Steve Jorgensen
<no****@nospam .nospam> wrote:

The way I understand timers, an ActiveX control (I'm thinking you are
planning on writing one) may not do the trick. WM_TIMER events are
used by the "normal" timers (SetTimer, the Timer control in VB and
Access) and they are low priority events, that only happen after all
other events are processed. They are also combined to a single event
if their time has expired before they got a change to tick.

The multimedia timer timeSetEvent ticks more predictably, but at the
price of consuming more CPU resources.

-Tom.

I've recently been playing with some UI ideas that require the user of a timer
to drive animation. The problem I'm having is that Access routinely stops
firing timer events for long periods of time.

For example, the user types a character in another window, and the timer
stops. The user types another key, and the timer starts again, runs for a few
seconds, then stops again.

Now, the code I'm writing would easily tolerate a few dropped timer event
firings, but these long pauses just don't work.

Of course, an ActiveX control might do the trick, but I also like to limit the
use of external controls because it makes the software harder to deploy,
especially for quick demos and such.

Does anyone have any clever solutions for this problem?

[Tom van Stiphout]

On Sun, 10 Apr 2005 20:46:11 -0700, Steve Jorgensen
<no****@nospam. nospam> wrote:

Surprise!
AFAIK, the timer control in Access is just a very thin veneer around
SetTimer.

-Tom.

Actually, the low-priority nature of the timer wouldn't be a problem for my
code in and of itself. It's just the fact that timer events can go on
vacation for very long periods of time. I don't know if this is an Access
behavior or a WM_TIMER behavior, but I would be a bit surprised if WM_TIMER
acted that way.

On Sun, 10 Apr 2005 12:01:55 -0700, Tom van Stiphout <no************ *@cox.net>
wrote:

On Sat, 09 Apr 2005 21:04:27 -0700, Steve Jorgensen
<no****@nospa m.nospam> wrote:

The way I understand timers, an ActiveX control (I'm thinking you are
planning on writing one) may not do the trick. WM_TIMER events are
used by the "normal" timers (SetTimer, the Timer control in VB and
Access) and they are low priority events, that only happen after all
other events are processed. They are also combined to a single event
if their time has expired before they got a change to tick.

The multimedia timer timeSetEvent ticks more predictably, but at the
price of consuming more CPU resources.

-Tom.

I've recently been playing with some UI ideas that require the user of a timer
to drive animation. The problem I'm having is that Access routinely stops
firing timer events for long periods of time.

For example, the user types a character in another window, and the timer
stops. The user types another key, and the timer starts again, runs for a few
seconds, then stops again.

Now, the code I'm writing would easily tolerate a few dropped timer event
firings, but these long pauses just don't work.

Of course, an ActiveX control might do the trick, but I also like to limit the
use of external controls because it makes the software harder to deploy,
especially for quick demos and such.

Does anyone have any clever solutions for this problem?

[Steve Jorgensen]

I'm sure you're tight, but how thin? Do we know that Access does not shut
down handling of the timer when it feels like it?

On Sun, 10 Apr 2005 21:58:54 -0700, Tom van Stiphout <no************ *@cox.net>
wrote:

On Sun, 10 Apr 2005 20:46:11 -0700, Steve Jorgensen
<no****@nospam .nospam> wrote:

Surprise!
AFAIK, the timer control in Access is just a very thin veneer around
SetTimer.

-Tom.

Actually, the low-priority nature of the timer wouldn't be a problem for my
code in and of itself. It's just the fact that timer events can go on
vacation for very long periods of time. I don't know if this is an Access
behavior or a WM_TIMER behavior, but I would be a bit surprised if WM_TIMER
acted that way.

On Sun, 10 Apr 2005 12:01:55 -0700, Tom van Stiphout <no************ *@cox.net>
wrote:

On Sat, 09 Apr 2005 21:04:27 -0700, Steve Jorgensen
<no****@nosp am.nospam> wrote:

The way I understand timers, an ActiveX control (I'm thinking you are
planning on writing one) may not do the trick. WM_TIMER events are
used by the "normal" timers (SetTimer, the Timer control in VB and
Access) and they are low priority events, that only happen after all
other events are processed. They are also combined to a single event
if their time has expired before they got a change to tick.

The multimedia timer timeSetEvent ticks more predictably, but at the
price of consuming more CPU resources.

-Tom.
I've recently been playing with some UI ideas that require the user of a timer
to drive animation. The problem I'm having is that Access routinely stops
firing timer events for long periods of time.

For example, the user types a character in another window, and the timer
stops. The user types another key, and the timer starts again, runs for a few
seconds, then stops again.

Now, the code I'm writing would easily tolerate a few dropped timer event
firings, but these long pauses just don't work.

Of course, an ActiveX control might do the trick, but I also like to limit the
use of external controls because it makes the software harder to deploy,
especiall y for quick demos and such.

Does anyone have any clever solutions for this problem?

[David Schofield]

On Sun, 10 Apr 2005 23:15:39 -0700, in comp.databases. ms-access you
wrote:

I'm sure you're tight, but how thin? Do we know that Access does not shut
down handling of the timer when it feels like it?

Hi Steve
A quote of yours from the past:

From: Steve Jorgensen (no****@nospam. nospam)
Subject: Re: Blinking controls
Newsgroups: comp.databases. ms-access
Date: 2000-09-08 15:11:08 PST

After all, anyone who would try to drive a real-time
process in Access is terribly misguided to begin with.

!!!!
David