Losing Focus

[LabGeek]

I have an Access application that I have created that collects data
from a scanner and from a weighting scale. The data from the scanner
are unique identifiers (barcodes) and the scanner is connected as a
keyboard wedge. The data from the scale are weights and are
collected
by com port using MScomm32.ocx.

A user will scan a barcode into a text box (linked to a table field)
and then weight a sample. The weight will be collected from the com
port and directly updated to the table. To insure the user that the
weight was successfully captured, I have included a listbox which
queries the table after each scale recording. This way the user can
see their data show up on the screen in a mock spreadsheet.
My problem is that about 1 in 100 barcode scans do not completely
read. I have traced this error to the requerying of the listbox
control. If a barcode is being read in at the same time as the
listbox is being updated, there is a slight chance of the text box
(in
which the barcode is being entered) losing focus for a split second.
Since the computer sees the scanner as a keyboard wedge, it sends the
data to whatever has focus. When the text box loses focus, I lose
part of the barcode.
Is there a way to maintain focus on the text box no matter what
background processes are running? Or better yet is there a better
way
to run a query that doesn't take focus away from foreground
processes?
Thanks.

[Tim Marshall]

LabGeek wrote:

A user will scan a barcode into a text box (linked to a table field)

<snip>

Is there a way to maintain focus on the text box no matter what
background processes are running? Or better yet is there a better
way
to run a query that doesn't take focus away from foreground
processes?

If you're inputting two things at once, then you run the risk of the
problem you describe. What about not requerying the list box control
except as the after update event of the text box that receives the scan?
You may have to change your interface on the form so that the user
knows s/he should weigh the sample first and then scan the bar code.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Be Careful, Big Bird!" - Ditto "TIM-MAY!!" - Me

[LabGeek]

On Feb 21, 12:03 pm, Tim Marshall
<[e-mail]:

LabGeek wrote:

A user will scan a barcode into a text box (linked to a table field)

<snip>

Is there a way to maintain focus on the text box no matter what
background processes are running? Or better yet is there a better
way
to run a query that doesn't take focus away from foreground
processes?

If you're inputting two things at once, then you run the risk of the
problem you describe. What about not requerying the list box control
except as the after update event of the text box that receives the scan?
You may have to change your interface on the form so that the user
knows s/he should weigh the sample first and then scan the bar code.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Be Careful, Big Bird!" - Ditto "TIM-MAY!!" - Me

Tim,

Thanks for the reply. There are two users in this process. One is
scanning the barcode and taking another measurement which is being
"picked" off a list of barcodes adn the second person is weighting.
The way it is set up, both operators can run independantly of each
other as long as 1) there has been a barcode scanned in for the
record, and 2)they keep the samples in order. This way, person one
can scan multiple samples and be ahead of person two who is doing the
weighting. The scale sends the data to the record with the oldest
timestamp that doesn't have a weight and then updates the screen
(list). This was neither person has to wait for a sample to be
totally completed before starting the next one.

When things are timed just right I have no problems, but when the
people taking the measurements get just out of synch (or are operating
fast) then I get the chance of the list box running a query at the
same time the scaner is reading a bar code. When this happens, there
is the smallest window of time when the text box loses focus and we
lose some of the scanned barcode.

I have tried adding conditions such as "don't query if the text box <>
"" " but this seems to confuse people when the hear the scale beep but
the screen hasn't updated to show the weight has sucessfully taken.

[lesperancer]

is the listbox locked ? or disabled ? wouldn't that prevent it from
getting focus ?

how is the listbox updated ? a timer event ?
On Feb 21, 2:37 pm, "LabGeek" <[e-mail]:

On Feb 21, 12:03 pm, Tim Marshall

<[e-mail]:

LabGeek wrote:

A user will scan a barcode into a text box (linked to a table field)

<snip>

Is there a way to maintain focus on the text box no matter what
background processes are running? Or better yet is there a better
way
to run a query that doesn't take focus away from foreground
processes?

If you're inputting two things at once, then you run the risk of the
problem you describe. What about not requerying the list box control
except as the after update event of the text box that receives the scan?
You may have to change your interface on the form so that the user
knows s/he should weigh the sample first and then scan the bar code.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Be Careful, Big Bird!" - Ditto "TIM-MAY!!" - Me

Tim,

Thanks for the reply. There are two users in this process. One is
scanning the barcode and taking another measurement which is being
"picked" off a list of barcodes adn the second person is weighting.
The way it is set up, both operators can run independantly of each
other as long as 1) there has been a barcode scanned in for the
record, and 2)they keep the samples in order. This way, person one
can scan multiple samples and be ahead of person two who is doing the
weighting. The scale sends the data to the record with the oldest
timestamp that doesn't have a weight and then updates the screen
(list). This was neither person has to wait for a sample to be
totally completed before starting the next one.

When things are timed just right I have no problems, but when the
people taking the measurements get just out of synch (or are operating
fast) then I get the chance of the list box running a query at the
same time the scaner is reading a bar code. When this happens, there
is the smallest window of time when the text box loses focus and we
lose some of the scanned barcode.

I have tried adding conditions such as "don't query if the text box <>
"" " but this seems to confuse people when the hear the scale beep but
the screen hasn't updated to show the weight has sucessfully taken.- Hide quoted text -

- Show quoted text -

[LabGeek]

On Feb 21, 4:05 pm, [e-mail] wrote:

is the listbox locked ? or disabled ? wouldn't that prevent it from
getting focus ?

how is the listbox updated ? a timer event ?

On Feb 21, 2:37 pm, "LabGeek" <[e-mail]:

On Feb 21, 12:03 pm, Tim Marshall

<[e-mail]:

LabGeek wrote:
A user will scan a barcode into a text box (linked to a table field)
<snip>
Is there a way to maintain focus on the text box no matter what
background processes are running? Or better yet is there a better
way
to run a query that doesn't take focus away from foreground
processes?

If you're inputting two things at once, then you run the risk of the
problem you describe. What about not requerying the list box control
except as the after update event of the text box that receives the scan?
You may have to change your interface on the form so that the user
knows s/he should weigh the sample first and then scan the bar code.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Be Careful, Big Bird!" - Ditto "TIM-MAY!!" - Me

Tim,

Thanks for the reply. There are two users in this process. One is
scanning the barcode and taking another measurement which is being
"picked" off a list of barcodes adn the second person is weighting.
The way it is set up, both operators can run independantly of each
other as long as 1) there has been a barcode scanned in for the
record, and 2)they keep the samples in order. This way, person one
can scan multiple samples and be ahead of person two who is doing the
weighting. The scale sends the data to the record with the oldest
timestamp that doesn't have a weight and then updates the screen
(list). This was neither person has to wait for a sample to be
totally completed before starting the next one.

When things are timed just right I have no problems, but when the
people taking the measurements get just out of synch (or are operating
fast) then I get the chance of the list box running a query at the
same time the scaner is reading a bar code. When this happens, there
is the smallest window of time when the text box loses focus and we
lose some of the scanned barcode.

I have tried adding conditions such as "don't query if the text box <>
"" " but this seems to confuse people when the hear the scale beep but
the screen hasn't updated to show the weight has sucessfully taken.- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

There are 5 basic contols on the form. 2 bound text boxes for
scanning in a barcode and a measurement, a text box for displaying
data from a scale, a graph for creating time course representation and
a list box to display all the data that will fit (this is so the users
can monitor the previous several records. The list box and graph are
fed from querys that are run each time there is a Form_update event.
The text boxes are not locked to allow data to be scanned directly
into them. The weight values that are shown on the screen are read
from the table after the com event records them from the scale.

Each time the scale records data, I must requery the table to place
the weight on the screen to "prove" to the user that the value has
been recorded. Sometimes during that query, a second user will scan a
barcode into the unlocked, bound text box (which creates a new record)
and there is a short interval that the text box loses focus and drops
characters.

Thank for the reply!

[lesperancer]

Are you sure that the textbox has lost focus... or is Access still
processing the form's
after_update() event ?

what happens if you move the requerying of the list box from the
after_update() event to the timer() event ?

are the listbox and graph controls enabled ? is so, why can't they be
disabled so that they can't get focus ?
On Feb 21, 3:49 pm, "LabGeek" <[e-mail]:

On Feb 21, 4:05 pm, [e-mail] wrote:

is the listbox locked ? or disabled ? wouldn't that prevent it from
getting focus ?

how is the listbox updated ? a timer event ?

On Feb 21, 2:37 pm, "LabGeek" <[e-mail]:

On Feb 21, 12:03 pm, Tim Marshall

<[e-mail]:
LabGeek wrote:
A user will scan a barcode into a text box (linked to a table field)
<snip>
Is there a way to maintain focus on the text box no matter what
background processes are running? Or better yet is there a better
way
to run a query that doesn't take focus away from foreground
processes?

If you're inputting two things at once, then you run the risk of the
problem you describe. What about not requerying the list box control
except as the after update event of the text box that receives the scan?
You may have to change your interface on the form so that the user
knows s/he should weigh the sample first and then scan the bar code.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Be Careful, Big Bird!" - Ditto "TIM-MAY!!" - Me

Tim,

Thanks for the reply. There are two users in this process. One is
scanning the barcode and taking another measurement which is being
"picked" off a list of barcodes adn the second person is weighting.
The way it is set up, both operators can run independantly of each
other as long as 1) there has been a barcode scanned in for the
record, and 2)they keep the samples in order. This way, person one
can scan multiple samples and be ahead of person two who is doing the
weighting. The scale sends the data to the record with the oldest
timestamp that doesn't have a weight and then updates the screen
(list). This was neither person has to wait for a sample to be
totally completed before starting the next one.

When things are timed just right I have no problems, but when the
people taking the measurements get just out of synch (or are operating
fast) then I get the chance of the list box running a query at the
same time the scaner is reading a bar code. When this happens, there
is the smallest window of time when the text box loses focus and we
lose some of the scanned barcode.

I have tried adding conditions such as "don't query if the text box <>
"" " but this seems to confuse people when the hear the scale beep but
the screen hasn't updated to show the weight has sucessfully taken.- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

There are 5 basic contols on the form. 2 bound text boxes for
scanning in a barcode and a measurement, a text box for displaying
data from a scale, a graph for creating time course representation and
a list box to display all the data that will fit (this is so the users
can monitor the previous several records. The list box and graph are
fed from querys that are run each time there is a Form_update event.
The text boxes are not locked to allow data to be scanned directly
into them. The weight values that are shown on the screen are read
from the table after the com event records them from the scale.

Each time the scale records data, I must requery the table to place
the weight on the screen to "prove" to the user that the value has
been recorded. Sometimes during that query, a second user will scan a
barcode into the unlocked, bound text box (which creates a new record)
and there is a short interval that the text box loses focus and drops
characters.

Thank for the reply!- Hide quoted text -

- Show quoted text -