[AccessD] shutting down

Good question, I believe a lot of those devices act as keyboard input,
not 100% sure on that.

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte
Foust
Sent: Monday, December 17, 2007 1:45 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] shutting down

Where would barcode scanners and pens fall within the spectrum of
whackability?

Charlotte Foust 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Monday, December 17, 2007 11:27 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] shutting down

As someone has already said, this is not built in to the application
(Access) and so there can be no guarantees.  OTOH there's no guarantee
that Access won't hang or that Windows won't hang.  The best you can do
is say that "if the form stays open and the timer is allowed to fire,
then it will work".  One issue is that in fact Access can and does hang,
queries can take days to complete etc.  VBA is single threaded so it
simply doesn't matter how you go about this, the thread that updates the
variable has to get control periodically.  If that fails then the
process fails.

This will be a 99% kinda thing, and yep, occasionally it will fail.  You
can't "not do something" because it might fail someday.  Something is
better than nothing, and this is a pretty good solution.  I think
(haven't actually studied it) that Drew's solution is probably as
airtight as you are going to get for the part it plays, but even that
just updates the variable.  The timer event still has to get control to
check the variable.

And you do need to have a published spec for any running processes that
do NOT involve keyboard / mouse to whack the variable periodically to
keep the app open.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
Sent: Monday, December 17, 2007 2:05 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] shutting down

> To apply that concept to your application, you would create a table 
> variable (local in this case) or even a global variable.  The timer on

> your form now modifies that table / global variable every time a new 
> control is sensed.
> This solves the "yea but they might have just come back to the same 
> control"
> issue.  Similarly any process that needs to keep the application alive

> can update the table / local variable once every N time units.  How 
> the process does that is up to the process, but there would be a rule 
> "if the location is not updated for more than X time units you're 
> history".  Thus the application could do it once every time through a 
> loop etc.

=======John, this is similar to what I considered -- simply updating the
global variable. The function wouldn't even care which control updated
the variable. My main concern with any of these solutions is that it not
have cracks -- actions that don't update the variable, and that all that
updating doesn't impact performance.

Susan H. 


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com