[AccessD] shutting down

It depends.  Barcode scanners come in two major varieties, wedges and
serial.  Wedges insert data into the keyboard stream and so ASSUMING that
the Access application had the focus, it would be treated as a keypress by
the Access application.  Serial barcode scanners OTOH send data over the
serial port.  As such they would need to "whack" the variable.  OTOH, if
they are the ONLY input (or might be in some cases) then this whole concept
falls apart since you would more likely want a simple "between this time and
that time" kind of thing where the application is allowed to stay open from
start of business till end of business or something similar.  

This is a perfect example of where a simple "no activity" falls apart, and
as such should not be implemented for that case.

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 Charlotte Foust
Sent: Monday, December 17, 2007 2: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