fast

[WindAndWaves]

Hi Gurus

What is the fatest way to select all the items in a list box?

At the moment, I do this for each itm in ctl..... type of method, but with
more than 2,000 items, this can be a little slow.....

are there any commands that do the whole thing at once???

TIA

- Nicolaas

[Tony Toews]

"WindAndWaves" <ac****@ngaru.com> wrote:

What is the fatest way to select all the items in a list box?

At the moment, I do this for each itm in ctl..... type of method, but with
more than 2,000 items, this can be a little slow.....

are there any commands that do the whole thing at once???

Alternatively try turning echo off. Note that you'd best ensure you have an error
handling routine and turn echo on as the first thing in your error handling routine
or you'll never see any error messages and your app will be "frozen".

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[David W. Fenton]

"WindAndWaves" <ac****@ngaru.com> wrote in
news:X%*******************@news.xtra.co.nz:

What is the fatest way to select all the items in a list box?

At the moment, I do this for each itm in ctl..... type of method,
but with more than 2,000 items, this can be a little slow.....

are there any commands that do the whole thing at once???

A listbox with 2000 items in is an abomination, user-hostile, a
performance nightmare.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[WindAndWaves]

Dear Mr Fenton

And why would that be??? I guess you are right, may be I should rethink the
whole thing....

[rkc]

"WindAndWaves" <ac****@ngaru.com> wrote in message
news:dK*******************@news.xtra.co.nz...

Dear Mr Fenton

And why would that be??? I guess you are right, may be I should rethink the whole thing....

If you're building something that will be used by other people, ask them.

[Larry Linson]

"WindAndWaves" <ac****@ngaru.com> wrote

And why would that be??? I guess you
are right, may be I should rethink the
whole thing....

The Microsoft publication "The Windows Interface - a Design Guide" (written
in Win 3.1 days) recommended no more than 20 - 50 items in a list that you
force your users to scroll through. Windows has changed since then, but
users have not.

A good reason: I would try an application that forced me to scroll through
2000 items just long enough to discover that's what it did, before
uninstalling it from my computer as _unusable_. I suspect I am not that
different from your users when it comes to long, long scrolls.

Larry Linson
Microsoft Access MVP

[Tom van Stiphout]

On Tue, 29 Jun 2004 09:23:44 +1200, "WindAndWaves" <ac****@ngaru.com>
wrote:

Why don't you tell us a bit more about what you want to accomplish
from a 10,000 foot level (approx 3048 meters :-)), so we may be able
to suggest alternatives.

-Tom.

Hi Gurus

What is the fatest way to select all the items in a list box?

At the moment, I do this for each itm in ctl..... type of method, but with
more than 2,000 items, this can be a little slow.....

are there any commands that do the whole thing at once???

TIA

- Nicolaas

[almish]

"WindAndWaves" <ac****@ngaru.com> wrote in message news:<dK*******************@news.xtra.co.nz>...

Dear Mr Fenton

And why would that be??? I guess you are right, may be I should rethink the
whole thing....

Here's some thoughts that may be more helpful to you. If the combo box
has more than 100 choices it becomes a bit much for users to find what
they want and you are probably better off providing a search form for
them. This will perform better and be more helpful than making the
user wait while 2000+ records are sent over the network to the local
form and then making them scroll through them to find what they want.

There is some great reading here:

http://www.attcanada.net/~kallal.msn/Search/index.html

That will help define the issue and hopefully provide some
inspiration.

The key issue here is that the slowest part of database access is the
network - anything you can do to minimize the amount of data or number
of round-trips needed to get data over the network will make your
application more responsive, i.e., a "snappier" interface for your
users.

'---------------
' John Mishefske
'---------------

[Larry Daugherty]

Hi NIcolaas,

I echo the sentiments of others here as to the number of items that might
belong in list boxes, comboboxes, etc. However, you could add a SelectAll
command button near your listbox and in its code index through the items in
the listbox setting

ListBox(I).Selected=True.

You must already have code to test for selected = True so writing the new
code should be a breeze.

HTH

p.s. One customer of mine (a department in a Huge bank) insisted that they
have their world-wide commercial borrower names and accounts searchable via
comboboxes. They wouldn't be dissuaded. There were something over 100,000
customers ... The first hit took about 20 seconds, subsequent hits about 5
seconds each.

--
-Larry-
--

"Larry Linson" <bo*****@localhost.not> wrote in message
news:tz*******************@nwrddc03.gnilink.net...

"WindAndWaves" <ac****@ngaru.com> wrote

> And why would that be??? I guess you
> are right, may be I should rethink the
> whole thing....
The Microsoft publication "The Windows Interface - a Design Guide"

(written in Win 3.1 days) recommended no more than 20 - 50 items in a list that you
force your users to scroll through. Windows has changed since then, but
users have not.

A good reason: I would try an application that forced me to scroll through
2000 items just long enough to discover that's what it did, before
uninstalling it from my computer as _unusable_. I suspect I am not that
different from your users when it comes to long, long scrolls.

Larry Linson
Microsoft Access MVP

[Rick Brandt]

"Larry Linson" <bo*****@localhost.not> wrote in message
news:tz*******************@nwrddc03.gnilink.net...

"WindAndWaves" <ac****@ngaru.com> wrote

> And why would that be??? I guess you
> are right, may be I should rethink the
> whole thing....
The Microsoft publication "The Windows Interface - a Design Guide"

(written in Win 3.1 days) recommended no more than 20 - 50 items in a list that you force your users to scroll through. Windows has changed since then, but
users have not.

A good reason: I would try an application that forced me to scroll through 2000 items just long enough to discover that's what it did, before
uninstalling it from my computer as _unusable_. I suspect I am not that
different from your users when it comes to long, long scrolls.

An assumption is being made here. That the app is forcing or expecting you
to scroll through all the rows it exposes. Not every ListBox is a bound
data control used to make entries. In many of my forms a ListBox is used
as a navigation or record selector. This was done explicitly for the
reason that I didn't want to load lots of records, but rather provide an
intuitive way for the user to specify those records that they need to see.

To that end the ListBox picks a couple of columns meaningful enough to the
user to let them select that particular record for viewing. The form then
has tools on it to provide filtering of the ListBox to narrow the choices.
In most cases I default the ListBox to zero rows and only populate it when
some filter criteria has been provided.

The user could very well enter a filter criteria that returns a couple
thousand rows. This does not mean that the user is expected to scroll
through the entire list. If the user has a brain in their head they know
that when the list is large it means they need to narrow their criteria
some more. In other cases the user is interested in reviewing "some"
records that satisfy a certain criteria. That criteria might result in
5000 rows in the ListBox, but they only need to review the first 5 or 6 to
accomplish their goal.

I'm not disagreeing with the basic UI premise that short lists are better
than long lists, but it bugs me a bit when I see these overly broad
statements along the lines of "any list with more than 100 rows is bad
design". What matters is whether it works well for the intended purpose.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Larry Linson]

List boxes are for scrolling (well, not if the list is sufficiently short)
and selection of information, whether bound or not. The original poster said
the list box had 2000 items. I was not, repeat not, dealing with "select
all" but with the design of the list box itself.

I'll stand by my statement, too, that any list box that [ever|normally]
requires a user to scroll through 2000 items is unusable in any practical
sense. And, if it were always a "Select All" situation, why bother with a
List Box? You certainly can't size it to show all 2000 list items, unless
you have a wall-size display, and even so, it'd have to be a large wall.

Larry Linson
Microsoft Access MVP
"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:2k***********@uni-berlin.de...

"Larry Linson" <bo*****@localhost.not> wrote in message
news:tz*******************@nwrddc03.gnilink.net...

"WindAndWaves" <ac****@ngaru.com> wrote

> And why would that be??? I guess you
> are right, may be I should rethink the
> whole thing....
The Microsoft publication "The Windows Interface - a Design Guide"

(written

in Win 3.1 days) recommended no more than 20 - 50 items in a list that

you

force your users to scroll through. Windows has changed since then, but
users have not.

A good reason: I would try an application that forced me to scroll

through

2000 items just long enough to discover that's what it did, before
uninstalling it from my computer as _unusable_. I suspect I am not that
different from your users when it comes to long, long scrolls.

An assumption is being made here. That the app is forcing or expecting

you to scroll through all the rows it exposes. Not every ListBox is a bound
data control used to make entries. In many of my forms a ListBox is used
as a navigation or record selector. This was done explicitly for the
reason that I didn't want to load lots of records, but rather provide an
intuitive way for the user to specify those records that they need to see.

To that end the ListBox picks a couple of columns meaningful enough to the
user to let them select that particular record for viewing. The form then
has tools on it to provide filtering of the ListBox to narrow the choices.
In most cases I default the ListBox to zero rows and only populate it when
some filter criteria has been provided.

The user could very well enter a filter criteria that returns a couple
thousand rows. This does not mean that the user is expected to scroll
through the entire list. If the user has a brain in their head they know
that when the list is large it means they need to narrow their criteria
some more. In other cases the user is interested in reviewing "some"
records that satisfy a certain criteria. That criteria might result in
5000 rows in the ListBox, but they only need to review the first 5 or 6 to
accomplish their goal.

I'm not disagreeing with the basic UI premise that short lists are better
than long lists, but it bugs me a bit when I see these overly broad
statements along the lines of "any list with more than 100 rows is bad
design". What matters is whether it works well for the intended purpose.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Trevor Best]

WindAndWaves wrote:

Hi Gurus

What is the fatest way to select all the items in a list box?

At the moment, I do this for each itm in ctl..... type of method, but with
more than 2,000 items, this can be a little slow.....

are there any commands that do the whole thing at once???

TIA

- Nicolaas

I still use my time honored way of making multiple selections from the
days before multiselect listboxes were available in Access, that is to
use 2 listboxes, the LH box has unselected items and the RH box has
selected items, there'll be field in the record for selecting, a select
all function would just batch update all the unselected items to
selected with a query and requery the listboxes, this generally occurs
in less than half a second even for large selections.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[WindAndWaves]

Hey Trevor

that is a brilliant idea! Thank you.

[WindAndWaves]

To answer some of the questions:

I have, at times, several thousands items in the list boxes, but they are
not randomly displayed.

The listbox is in my printer manager. The print manager is a form that the
user can use to print reports.

They may, for example, say "filter by contacts" and there may be several
thousand contacts in the list. However, because they are sorted
alphabetically, all they need to do is scroll down the list to the
appropriate first letter, and so on. A bit like a telephone book.

I could add a search function for the lookup list, but at the mo moment, a
need to first make sure that the basics in the print manager work.

Thank you all for your interesting replies

- Nicolaas

[John Mishefske]

WindAndWaves wrote:

To answer some of the questions:

I have, at times, several thousands items in the list boxes, but they are
not randomly displayed.

The listbox is in my printer manager. The print manager is a form that the
user can use to print reports.

They may, for example, say "filter by contacts" and there may be several
thousand contacts in the list. However, because they are sorted
alphabetically, all they need to do is scroll down the list to the
appropriate first letter, and so on. A bit like a telephone book.

I could add a search function for the lookup list, but at the mo moment, a
need to first make sure that the basics in the print manager work.

Thank you all for your interesting replies

Check out these pages for some illuminating ideas:

http://www.attcanada.net/~kallal.msn/Search/index.html

--
'-------------------------------
' John Mishefske
'-------------------------------