By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,285 Members | 2,124 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,285 IT Pros & Developers. It's quick & easy.

Timer events that must occur

P: n/a
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?
Nov 13 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
On Apr 10 2005, 12:04 am, Steve Jorgensen <no****@nospam.nospam> wrote
in news:h2********************************@4ax.com:
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
Nov 13 '05 #2

P: n/a
On Sun, 10 Apr 2005 15:33:26 -0000, Dimitri Furman <df*****@cloud99.net>
wrote:
On Apr 10 2005, 12:04 am, Steve Jorgensen <no****@nospam.nospam> wrote
in news:h2********************************@4ax.com:
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?
Nov 13 '05 #3

P: n/a
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?


Nov 13 '05 #4

P: n/a
On Apr 10 2005, 03:01 pm, Steve Jorgensen <no****@nospam.nospam> wrote
in news:5t********************************@4ax.com:
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
Nov 13 '05 #5

P: n/a
On Mon, 11 Apr 2005 02:11:54 -0000, Dimitri Furman <df*****@cloud99.net>
wrote:
On Apr 10 2005, 03:01 pm, Steve Jorgensen <no****@nospam.nospam> wrote
in news:5t********************************@4ax.com:
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.
Nov 13 '05 #6

P: n/a
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?


Nov 13 '05 #7

P: n/a
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****@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?


Nov 13 '05 #8

P: n/a
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****@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?


Nov 13 '05 #9

P: n/a
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
Nov 13 '05 #10

P: n/a
On Sun, 10 Apr 2005 23:15:39 -0700, Steve Jorgensen
<no****@nospam.nospam> wrote:

There would be no point. WM_TIMER does this all by itself (well, the
OS does it), since it's a low-priority message.

-Tom.

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****@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?


Nov 13 '05 #11

P: n/a
On 11 Apr 2005 04:12:02 -0500, d.***************@blueyonder.co.uk (David
Schofield) wrote:
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


Well, there's real-time, and then there's real-time. I'm was expecting to be
able to use a timer for about 10 seconds at a shot, and hope to get at least
most of the event firings. I'm not expecting to use an Access app as a
stand-alone service, and expect it to be reliable.
Nov 13 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.