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?
11  2537 
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
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?
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?
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
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.
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?
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?
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?
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
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?
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Laughlin, Joseph V |
last post by:
If I want a function to be called every second, how would I do this?
Would I use timer events?
Joe Laughlin
Phantom Works - Integrated Technology Development Labs
The Boeing Company
|
by: walterd |
last post by:
Hi
How can I cause a windows service to fire the timer_elapsed event for
different time intervals? I have a windows service that should run some
processed at 3 minute interval, but I also want...
|
by: keithgell |
last post by:
I needed to import large CSV files into Access, when requested by a
command in a .Net interface.
Because Access does not have a bulk insert command, and I already have
vba macros in Access that...
|
by: Max |
last post by:
This may be an elementary question but it's something I have not encountered
in about 10 years writing code in VB 5 / 6
I have a timer that using the API checks if there has been a change to one...
|
by: Helmut Jarausch |
last post by:
Hi,
I'm using a web server (Karrigell) which is based on the asyncore module.
I'd like to be able to checkpoint some data (e.g. pickled dictionaries) to disk
from time to time.
For that I would...
|
by: Jason C |
last post by:
Using C++, platform is Windows XP SP3.
I have a multimedia application that runs a rendering loop that must
be throttled to 60 iterations / second max. Currently it is
implemented using a dirty...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
