Select multiple items from list

[r. howell]

This has got to be something that people do all the time, but I'm having a
lot of trouble finding examples.

I have two situations in which I would like to give people a fairly
elaborate set of options to choose from:

In one case, it is a list of contractors, but I need to allow the user to
choose filters on the fly, and most importantly, my end user needs to have
enough information showing about each contractor that she can glance down the
list and check, yes/no for each contractor. The filters will get us within
shooting range, but at this point, our firm needs and wants to rely on
personal judgment backed by years of experience. Once we have items
selected, we need to use those choices in order to generate a number of
different reports (address labels,for one).

In the other case, clients need to choose from a number of possible
alternates, once bids have been received on a project. We need to use the
selected options to recalculate totals, and compare bids. Ideally, the
customer should be able to label and save several different scenarios. Can
anyone point me to vocabulary words, or to samples where someone is doing
something roughly similar?

I am thinking that my best bet may be not be a dropdown list but a subform
based on a query with a temporary or permanent table to list the different
mailings or the different contract scenarios. But I would really appreciate
some advice.

Thanks

 

[Tim Ferguson]

In one case, it is a list of contractors, but I need to allow the user
to choose filters on the fly, and most importantly, my end user needs
to have enough information showing about each contractor that she can
glance down the list and check, yes/no for each contractor.

There are a number of ways you could design a UI to do this; much depends
on what data structures you have underneath.

One way would be to have a temp table of FiltersAvailable with a boolean
field to indicate whether the user actually chooses that filter or not;
you could present this as a continuous form or a datasheet and the user
could check or clear a check box connected to the boolean field.

Another way would be to have a list box set to multi-select, so that the
user could collect up which filters he or she wants and then your VBA
would write the selected items to an appropriate FiltersWanted table.

A variation on that would be to allow the user drag-and-drop from the
list box to another control: not trivial and I've never done it, but I
have seen demonstration code (try Googling).

Hope that helps


Tim F

 

[r. howell]

Thanks for your response.

The filters-on-the-fly piece was probably a red herring, though I appreciate
your advice on how to handle it.

My real question is what the best way is to get a fair amount of data, in
multiple fields, to show up and allow the user to select the records they
want to deal with (perhaps selecting as many as 50-100 from a list of 250. A
Drop down list with multiple-select does not seem ideal to me. I would
prefer some way to let the user scan down a list of records and check a
yes/no box for on the ones that they like.

I wonder why I don't see more examples of things like this. Am I looking in
the wrong place? Calling it the wrong thing? Or does Access really not
allow this?

 

[Tim Ferguson]

My real question is what the best way is to get a fair amount of data,
in multiple fields, to show up and allow the user to select the
records they want to deal with (perhaps selecting as many as 50-100
from a list of 250. A Drop down list with multiple-select does not
seem ideal to me. I would prefer some way to let the user scan down a
list of records and check a yes/no box for on the ones that they like.

I hate to say this, but this sounds like a case of More Analysis Needed.
When you really get down to business cases, the things needed should be
identifiable. Actual information flows, dependencies, business processes
can be mapped individually and the appropriate support devised. For my
money, it's not really on for the designer to turn back to the client and
say, "here's the data, just learn SQL" although that is, by definition,
the most 'flexible' approach. IME that word, "flexible" in a requirements
analysis just means "I haven't had time to work through this yet".

Unless, of course, you are intending to build a database programming
platform... Have you introduced your users to MS Query?

I wonder why I don't see more examples of things like this. Am I
looking in the wrong place? Calling it the wrong thing? Or does
Access really not allow this?

Access will allow virtually anything you want to do: the problem is not
the platform. You don't see many examples like this because they don't
succeed. The ones you see working (it's a bit Darwinian this) are the
ones that have been correctly systems-analysed, the problems identified
and solution achieved. That means specific tools to accomplish specific
business goals.


Sorry!

B Wishes


Tim F

 

[John Vinson]

Thanks for your response.

The filters-on-the-fly piece was probably a red herring, though I appreciate
your advice on how to handle it.

My real question is what the best way is to get a fair amount of data, in
multiple fields, to show up and allow the user to select the records they
want to deal with (perhaps selecting as many as 50-100 from a list of 250. A
Drop down list with multiple-select does not seem ideal to me. I would
prefer some way to let the user scan down a list of records and check a
yes/no box for on the ones that they like.

I wonder why I don't see more examples of things like this. Am I looking in
the wrong place? Calling it the wrong thing? Or does Access really not
allow this?

Reread Tim's first suggestion: it does exactly and specifically what
you're asking for.

Just add a Yes/No (Boolean is another term for it) field to the table,
and use a subform to let the user check the checkbox for that field.

John W. Vinson[MVP]

 

[r. howell]

I hate to say this, but this sounds like a case of More Analysis Needed.
When you really get down to business cases, the things needed should be
identifiable. Actual information flows, dependencies, business processes
can be mapped individually and the appropriate support devised. For my
money, it's not really on for the designer to turn back to the client and
say, "here's the data, just learn SQL" although that is, by definition,
the most 'flexible' approach. IME that word, "flexible" in a requirements
analysis just means "I haven't had time to work through this yet".

Thanks. (and with help from both of you, I think I've got this working, and
I'll teach them how to use "filter by form")

i'm not exactly a professional database designer working for a client. I'm
a secretary/theology student desperately trying to figure out how to make
this work for my firm, when they aren't quite ready to invest the time to do
the analysis and move it from one person who flies by the seat of her pants
and a lifetime of experience to specific details. If I can prove to them
that it can run and save them time, then I think they'll be willing to start
to figure out what the real criteria are. I'm trying to get into the
ballpark. Sooner or later, they'll need someone with more training than me.

 

[Tim Ferguson]

they aren't quite ready to invest the time to do
the analysis and move it from one person who flies by the seat of her
pants and a lifetime of experience to specific details.

<response class="smartass">If they can't afford to do it right, how come
they can afford to do it wrong..?</response>

Hope it works out
Best wishes



Tim F