stevbe
asked on
Multi-Select criteria builder
I understand how to build and apply criteria from multi-select list boxes but what I am noticing is that multi-select list boxeas ... well ... are not user friendly if you have to scroll. It starts to feel bad when you have to scroll a lot so I have started thinking about using tables to collect the criteria so they can use a combobox to select each criteria. I thought about this a little bit it on the ride in this morning but was wondering if anyone has used this approach and has any practical advice in implemeting this or reasons I should reconsider my approach.
TIA,
Steve
TIA,
Steve
rockiroads
What do u mean by critera, do u mean data or list of fields?
ASKER
Sorry for not being clear, still working on second cup of coffee :-)
This is for user selecting report criteria ... select one or more customers, pick one or more vendors, one or more internal contacts etc.
so I was thinking if I had a seperate table for each type of multi-select criteria I could build a 1 column datasheet for and use them as subforms on my main report selector and criteria form, this way they can type/select from the combobox (auto complete and all :-)) and enter as many as they would like. I would then open a recordset and build the WhereCondition in the usual way for multi-select listbox
Select Vendor Select Contact
---------------- --------------------
datasheet sub datasheet sub
* cbo * cbo
---------------- --------------------
This is for user selecting report criteria ... select one or more customers, pick one or more vendors, one or more internal contacts etc.
so I was thinking if I had a seperate table for each type of multi-select criteria I could build a 1 column datasheet for and use them as subforms on my main report selector and criteria form, this way they can type/select from the combobox (auto complete and all :-)) and enter as many as they would like. I would then open a recordset and build the WhereCondition in the usual way for multi-select listbox
Select Vendor Select Contact
---------------- --------------------
datasheet sub datasheet sub
* cbo * cbo
---------------- --------------------
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
<Some of your combo values are probably dependant on other combo's?>
no ... straight up ... no dependencies
<I assume then u have some button somewhere that says "ADD THIS CRITERIA">
no ... if they select something it is automatically included
<I would add in something like "All Vendors" or "All Contacts>
I will think about this ... they are use to the idea that selections restrict data but I understand the concept you are presenting and will give it another go around inside my head :-)
<make use of a standard query which has joins/inner queries to this temp table>
I was thinking not because there are actually 4 multi-select fields (which means I will have 4 criteria tables) they may or may not enter criteria in so I would need to have a version for each combination of joins or start writing the crazy Like "'*'" & Forms! ... "'*'" Like "'*'" nonsense that while I have gotten it correct in the past always takes me too long to get up to speed again when I go into maintenance mode :-)
<If not joins Im thinking take a preexisting query (using Querydefs) get the SQL and add your WHERE >
I typically leave the based SQL alone and pass the WHERE in the WhereCondition argument of DoCmd.OpenReport. just like I have in the past when using multi-select listboxes ... you know ... For Each varItem In lstVendor.ItemsSelected ...
<I guess u have a number of different reports also>
yes, I have a based query that includes all of the criteria fields and PK field and then for each report I build another query that joins my criteria query with the approriate table(s) to provide the rest of the field values for display on the report.
Thanks for the ideas, I really want to think about all aspects of rewriting my report criteria methodology before I spend the time. I am optimistic and may use this concept as a standard for all my apps as I try to reuse code, best practice UI, etc. for speeding development and consistency.
Steve
no ... straight up ... no dependencies
<I assume then u have some button somewhere that says "ADD THIS CRITERIA">
no ... if they select something it is automatically included
<I would add in something like "All Vendors" or "All Contacts>
I will think about this ... they are use to the idea that selections restrict data but I understand the concept you are presenting and will give it another go around inside my head :-)
<make use of a standard query which has joins/inner queries to this temp table>
I was thinking not because there are actually 4 multi-select fields (which means I will have 4 criteria tables) they may or may not enter criteria in so I would need to have a version for each combination of joins or start writing the crazy Like "'*'" & Forms! ... "'*'" Like "'*'" nonsense that while I have gotten it correct in the past always takes me too long to get up to speed again when I go into maintenance mode :-)
<If not joins Im thinking take a preexisting query (using Querydefs) get the SQL and add your WHERE >
I typically leave the based SQL alone and pass the WHERE in the WhereCondition argument of DoCmd.OpenReport. just like I have in the past when using multi-select listboxes ... you know ... For Each varItem In lstVendor.ItemsSelected ...
<I guess u have a number of different reports also>
yes, I have a based query that includes all of the criteria fields and PK field and then for each report I build another query that joins my criteria query with the approriate table(s) to provide the rest of the field values for display on the report.
Thanks for the ideas, I really want to think about all aspects of rewriting my report criteria methodology before I spend the time. I am optimistic and may use this concept as a standard for all my apps as I try to reuse code, best practice UI, etc. for speeding development and consistency.
Steve
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I always go with IN's as this is for reporting and the perf should not be too different either way so they can wait :-) and I don't have to worry about the number or ORs that Access can handle.
One beauty of a table based search is that it is then trivial to add "saved searches" - and to recall saved searches for use/editing :-)
ASKER
"saved searches" = v2.0
I am trying to figure out how *generic* I can make this process but I think I am always going to be stuck with modifing tbale names and delimiters per app.
I am trying to figure out how *generic* I can make this process but I think I am always going to be stuck with modifing tbale names and delimiters per app.
Yeah I'd imagine you need to.
Some kind of search config table that determines the available options in any given application.
(Available searching fields and their types could be listed in such a table too - if you store the field type it saves hitting the db to determine them at runtime).
You'd just have to set up your search config table when you create each db.
(You'd not want every table to be searchable - as if nothing else - they'd be report dependent won't they?)
Some kind of search config table that determines the available options in any given application.
(Available searching fields and their types could be listed in such a table too - if you store the field type it saves hitting the db to determine them at runtime).
You'd just have to set up your search config table when you create each db.
(You'd not want every table to be searchable - as if nothing else - they'd be report dependent won't they?)
One question, since u say u add the selected criteria straight away
do u give the users the option to combine two combo boxes to make one filter for a report? or is it strictly one combo per table per report kinda thing
Im wondering if u allow multiple combination filters, how then do u handle that
do u give the users the option to combine two combo boxes to make one filter for a report? or is it strictly one combo per table per report kinda thing
Im wondering if u allow multiple combination filters, how then do u handle that
Well - I was imagining either one combo for each field you want to filter on - and the relevant entries for each field (in lookup tables?) in each combo.
Select from a combo and an additional criteria added for that field with the selcted value...
or
One combo listing the fields - and a second one that adapts from the selection in the first to show appropriate lists.
Again - one click selection - critieria added based on field and value combos.
Naturally - the latter is more flexible with regards to the number of fields upon which you can limit the results (and hence port this from application to application).
Select from a combo and an additional criteria added for that field with the selcted value...
or
One combo listing the fields - and a second one that adapts from the selection in the first to show appropriate lists.
Again - one click selection - critieria added based on field and value combos.
Naturally - the latter is more flexible with regards to the number of fields upon which you can limit the results (and hence port this from application to application).
ASKER
<I was imagining either one combo for each field you want to filter on>
maybe I did not explain my thoughts clearly ...
take the simple example of selecting multiple criteria for a single field. Normally I use a multi-select listbox but I am thining that I can use a 1 field datasheet subform that has 1 combobox for that field so instead of picking multiple items in the listbox they enter multiple records using their combobox ... I think I am going to give this a whirl, maybe I will make a sample and post it to EE-Stuff.
maybe I did not explain my thoughts clearly ...
take the simple example of selecting multiple criteria for a single field. Normally I use a multi-select listbox but I am thining that I can use a 1 field datasheet subform that has 1 combobox for that field so instead of picking multiple items in the listbox they enter multiple records using their combobox ... I think I am going to give this a whirl, maybe I will make a sample and post it to EE-Stuff.
So how many fields do you search on?
You did have only one listbox? And now only one combo - but instead of multi select - it's add to a table for each combo click.
Just on the one field?
You did have only one listbox? And now only one combo - but instead of multi select - it's add to a table for each combo click.
Just on the one field?
ASKER
no ...current app is 4 multi-selects and 5 single selects, I have another we use here in IT that has 7 multis and 8 singles :-) Each multi and single is for a different field.
OK - so you'd then have 4 new combo's to replace each listbox?
So it's a multiple control search form - one per field?
So it's a multiple control search form - one per field?
ASKER
<OK> -- No, each listbox is replaced by a datatsheet form. Each datasheet form has 1 field and that field's control is a combobox.
<So> -- yes, but I am using a datasheet subform for each field instead of a multi-select listbox.
I should have a sample ready tomorrow so you can see how inept I am at explaining this :-)
<So> -- yes, but I am using a datasheet subform for each field instead of a multi-select listbox.
I should have a sample ready tomorrow so you can see how inept I am at explaining this :-)
Right - with you now.
(There must be a hundred ways of tackling this - hence the difficulty in seeing your particular vision).
I suppose UI requirements (screen real-estate) could determine different methods...
Cool
(There must be a hundred ways of tackling this - hence the difficulty in seeing your particular vision).
I suppose UI requirements (screen real-estate) could determine different methods...
Cool