I have a a form with a listbox. When the form is opened, a query is run to
populate the listbox. The query is somewhat slow (5 - 10 seconds depending
on network traffic). My users pointed out that after they open the form they
often click button X immediately to open another form. The button does not
seem to respond until after the listbox query is completed (needless to sat,
they are anoyed). I use the following code
------------------------------------------------------------------------------------------------

Private Sub Form_Timer()
On Error Resume Next 'Ok

'only run once:
Me.TimerInterval = 0

'load list and allow user to continue doing stuff:
Me.lstSamples.RowSource = "qryShowLabStats"

'continue processing events (so users can click btns):
DoEvents

End Su
------------------------------------------------------------------------------------------------
I just found the following in the help file:

In Microsoft Access, the DoEvents function is ignored if you use it in:

· A user-defined function or a procedure that calculates a field in a
query, form, or report.
· A user-defined function that creates a list to fill a combo box, a list
box, or an OLE object.

How about if when they click to open this form, you present a text box to the
user that says something like "Retrieving Data" and don't make the form
visible until the query completes?

"Hawkide" wrote:

> I have a a form with a listbox. When the form is opened, a query is run to
> populate the listbox. The query is somewhat slow (5 - 10 seconds depending
> on network traffic). My users pointed out that after they open the form they
> often click button X immediately to open another form. The button does not
> seem to respond until after the listbox query is completed (needless to sat,
> they are anoyed). I use the following code:
> ------------------------------------------------------------------------------------------------
>
> Private Sub Form_Timer()
> On Error Resume Next 'Ok
>
> 'only run once:
> Me.TimerInterval = 0
>
> 'load list and allow user to continue doing stuff:
> Me.lstSamples.RowSource = "qryShowLabStats"
>
> 'continue processing events (so users can click btns):
> DoEvents
>
> End Sub
> ------------------------------------------------------------------------------------------------
> I just found the following in the help file:
>
> In Microsoft Access, the DoEvents function is ignored if you use it in:
>
> · A user-defined function or a procedure that calculates a field in a
> query, form, or report.
> · A user-defined function that creates a list to fill a combo box, a list
> box, or an OLE object.

Well, I would prefer that the user does not have to wait, so I am really
looking for a solution that woulkd either let the query run in the background
while the Button_Click event is processed OR the query could actually stop
processing when the button is clicked.

"Klatuu" wrote:

> How about if when they click to open this form, you present a text box to the
> user that says something like "Retrieving Data" and don't make the form
> visible until the query completes?
>
> "Hawkide" wrote:
>
> > I have a a form with a listbox. When the form is opened, a query is run to
> > populate the listbox. The query is somewhat slow (5 - 10 seconds depending
> > on network traffic). My users pointed out that after they open the form they
> > often click button X immediately to open another form. The button does not
> > seem to respond until after the listbox query is completed (needless to sat,
> > they are anoyed). I use the following code:
> > ------------------------------------------------------------------------------------------------
> >
> > Private Sub Form_Timer()
> > On Error Resume Next 'Ok
> >
> > 'only run once:
> > Me.TimerInterval = 0
> >
> > 'load list and allow user to continue doing stuff:
> > Me.lstSamples.RowSource = "qryShowLabStats"
> >
> > 'continue processing events (so users can click btns):
> > DoEvents
> >
> > End Sub
> > ------------------------------------------------------------------------------------------------
> > I just found the following in the help file:
> >
> > In Microsoft Access, the DoEvents function is ignored if you use it in:
> >
> > · A user-defined function or a procedure that calculates a field in a
> > query, form, or report.
> > · A user-defined function that creates a list to fill a combo box, a list
> > box, or an OLE object.

I don't have any clever suggestions. Is your network very slow? Is the
database really large? Maybe there is a way to speed up your query by the
way you define it. One thing that may help is to create indexes on the
fields in the table the query is referencing.

Maybe you need faster computers or slower users

"Hawkide" wrote:

> Well, I would prefer that the user does not have to wait, so I am really
> looking for a solution that woulkd either let the query run in the background
> while the Button_Click event is processed OR the query could actually stop
> processing when the button is clicked.
>
> "Klatuu" wrote:
>
> > How about if when they click to open this form, you present a text box to the
> > user that says something like "Retrieving Data" and don't make the form
> > visible until the query completes?
> >
> > "Hawkide" wrote:
> >
> > > I have a a form with a listbox. When the form is opened, a query is run to
> > > populate the listbox. The query is somewhat slow (5 - 10 seconds depending
> > > on network traffic). My users pointed out that after they open the form they
> > > often click button X immediately to open another form. The button does not
> > > seem to respond until after the listbox query is completed (needless to sat,
> > > they are anoyed). I use the following code:
> > > ------------------------------------------------------------------------------------------------
> > >
> > > Private Sub Form_Timer()
> > > On Error Resume Next 'Ok
> > >
> > > 'only run once:
> > > Me.TimerInterval = 0
> > >
> > > 'load list and allow user to continue doing stuff:
> > > Me.lstSamples.RowSource = "qryShowLabStats"
> > >
> > > 'continue processing events (so users can click btns):
> > > DoEvents
> > >
> > > End Sub
> > > ------------------------------------------------------------------------------------------------
> > > I just found the following in the help file:
> > >
> > > In Microsoft Access, the DoEvents function is ignored if you use it in:
> > >
> > > · A user-defined function or a procedure that calculates a field in a
> > > query, form, or report.
> > > · A user-defined function that creates a list to fill a combo box, a list
> > > box, or an OLE object.

What is the nature of the query and the information that its retreiving?
It could be the design of the query is ineffiecent(sp) or that there
is another way to get the information. For that matter, what is
information is being presented in the list box?

Hawkide wrote:
> Well, I would prefer that the user does not have to wait, so I am really
> looking for a solution that woulkd either let the query run in the background
> while the Button_Click event is processed OR the query could actually stop
> processing when the button is clicked.
>
> "Klatuu" wrote:
>
>
>>How about if when they click to open this form, you present a text box to the
>>user that says something like "Retrieving Data" and don't make the form
>>visible until the query completes?
>>
>>"Hawkide" wrote:
>>
>>
>>>I have a a form with a listbox. When the form is opened, a query is run to
>>>populate the listbox. The query is somewhat slow (5 - 10 seconds depending
>>>on network traffic). My users pointed out that after they open the form they
>>>often click button X immediately to open another form. The button does not
>>>seem to respond until after the listbox query is completed (needless to sat,
>>>they are anoyed). I use the following code:
>>>------------------------------------------------------------------------------------------------
>>>
>>>Private Sub Form_Timer()
>>> On Error Resume Next 'Ok
>>>
>>>'only run once:
>>> Me.TimerInterval = 0
>>>
>>>'load list and allow user to continue doing stuff:
>>> Me.lstSamples.RowSource = "qryShowLabStats"
>>>
>>>'continue processing events (so users can click btns):
>>> DoEvents
>>>
>>>End Sub
>>>------------------------------------------------------------------------------------------------
>>>I just found the following in the help file:
>>>
>>>In Microsoft Access, the DoEvents function is ignored if you use it in:
>>>
>>>· A user-defined function or a procedure that calculates a field in a
>>>query, form, or report.
>>>· A user-defined function that creates a list to fill a combo box, a list
>>>box, or an OLE object.

You could do what my former company's IT department would probably
recommend - Tell the users that they're just going to have to wait.

Klatuu wrote:
> I don't have any clever suggestions. Is your network very slow? Is the
> database really large? Maybe there is a way to speed up your query by the
> way you define it. One thing that may help is to create indexes on the
> fields in the table the query is referencing.
>
> Maybe you need faster computers or slower users
>
> "Hawkide" wrote:
>
>
>>Well, I would prefer that the user does not have to wait, so I am really
>>looking for a solution that woulkd either let the query run in the background
>>while the Button_Click event is processed OR the query could actually stop
>>processing when the button is clicked.
>>
>>"Klatuu" wrote:
>>
>>
>>>How about if when they click to open this form, you present a text box to the
>>>user that says something like "Retrieving Data" and don't make the form
>>>visible until the query completes?
>>>
>>>"Hawkide" wrote:
>>>
>>>
>>>>I have a a form with a listbox. When the form is opened, a query is run to
>>>>populate the listbox. The query is somewhat slow (5 - 10 seconds depending
>>>>on network traffic). My users pointed out that after they open the form they
>>>>often click button X immediately to open another form. The button does not
>>>>seem to respond until after the listbox query is completed (needless to sat,
>>>>they are anoyed). I use the following code:
>>>>------------------------------------------------------------------------------------------------
>>>>
>>>>Private Sub Form_Timer()
>>>> On Error Resume Next 'Ok
>>>>
>>>>'only run once:
>>>> Me.TimerInterval = 0
>>>>
>>>>'load list and allow user to continue doing stuff:
>>>> Me.lstSamples.RowSource = "qryShowLabStats"
>>>>
>>>>'continue processing events (so users can click btns):
>>>> DoEvents
>>>>
>>>>End Sub
>>>>------------------------------------------------------------------------------------------------
>>>>I just found the following in the help file:
>>>>
>>>>In Microsoft Access, the DoEvents function is ignored if you use it in:
>>>>
>>>>· A user-defined function or a procedure that calculates a field in a
>>>>query, form, or report.
>>>>· A user-defined function that creates a list to fill a combo box, a list
>>>>box, or an OLE object.

Add another button to the form next to the listbox. Don't populate the
listbox until the user clicks the new button.

"Hawkide" wrote:

> I have a a form with a listbox. When the form is opened, a query is run to
> populate the listbox. The query is somewhat slow (5 - 10 seconds depending
> on network traffic). My users pointed out that after they open the form they
> often click button X immediately to open another form. The button does not
> seem to respond until after the listbox query is completed (needless to sat,
> they are anoyed). I use the following code:
> ------------------------------------------------------------------------------------------------
>
> Private Sub Form_Timer()
> On Error Resume Next 'Ok
>
> 'only run once:
> Me.TimerInterval = 0
>
> 'load list and allow user to continue doing stuff:
> Me.lstSamples.RowSource = "qryShowLabStats"
>
> 'continue processing events (so users can click btns):
> DoEvents
>
> End Sub
> ------------------------------------------------------------------------------------------------
> I just found the following in the help file:
>
> In Microsoft Access, the DoEvents function is ignored if you use it in:
>
> · A user-defined function or a procedure that calculates a field in a
> query, form, or report.
> · A user-defined function that creates a list to fill a combo box, a list
> box, or an OLE object.