Since you have just selected a value for the width, you can use a relationship to match to all records with that selected width. A conditional value list can use that relationship to list only lenghts available for the selected width. This will work even if you do not perform a find for all records with the selected width.
Thanks for the reply. In the long run I will be using about 13 different category in my project for searches.
Would I need to create a Table for each category?
1 of 1 people found this helpful
You would not. You just need a value list that lists your categories.
Here's a teaching file on the subject. I have been describing what is called a "Basic Conditional Value List".
Thanks, I'll look at it.
A follow up on my question.
If I need to make more than 1 selection. That is I need to select category "Length" then select category "Bins" (from the filtered "Length". ) Or, I select "Bins" and the select "Length" from the filtered list. Would I need the "Values" table only? In my current project I only have a Relation set for the "Product" and the "Image" for it. From your example (Hierarchical Conditional List 2") I would need to do the same in my project?
You certainly need relationships in order to get the value lists to work. That might need a new table or just a new table occurrence.
You are aware that this example uses calculation fields to produce various return separated lists of values? Whether the other field is empty or has a value determines which of two possible lists of ID's are used as match fields.
In every day language, what is the relationship between a "bin" and "length"?
What table in your solution holds this data now?
A table set up specifically for the values used in a value lists is often a good idea, but without a bit more info, I can't tell if that's something that you need here or not.
Thanks for taking the time to help.
I currently have a Table for the "Product" information. I have a Values table (ProductList).
The product it self is mainly numbers.
"Bens" is the number of slots that the product has. It is for "Cards", "Flyers" ect.
Length, Width, and Depth is the size of the product. (Note I do not have Height this is per the data that I have. Seems strange but!!!).
The only thing that is not a numeric value is the "Description" of the product.
I have about 14 categories that the may be used to narrow the search for a "Product" as far as possible so that it can viewed.
Yes, I saw the formulas used. But, did not completely understand.
1 of 1 people found this helpful
So you have a table of products with at least these fields?
ProductID Bins Length Description
The basic concept here uses a return separated list of Product ID's to match to different subsets of records in the above table. The calculation keeps you from having to select a value in field one before you can select in field 2. If you do select in field 1, the list of choices filters to a smaller number of values. If you don't select a value in field 1, you get a list of all products in field 2's value list. This avoids the "no values" error text that would appear in a conventional conditional value list if you didn't first select value in field 1.
A return separated list of values is an "or" relationship. Example, if you had these product ID's in a single field:
A relationship using this field to match to your productID field would match to product ID 1, OR product ID 2 OR Product ID 3.
THe example you referred to uses relationships and the List function to get different lists of ID's depending on whether the other fields are empty or not. A later example uses ExecuteSQL to get such a list of IDs.
Let's take a look at how Bins might be set up with such a value list:
First, you need a relationship to Products that will return the ID's of all products in the products table:
LayoutTable::anyField X Products|All::anyField
With the x operator selected instead of = (double click the relationship line to change), nearly any field in your layout's table occrrence can match to any field in Products|All and this will work. Products|All is a table occurrence of your Products table.
Then you need a second relationship and a new occurrence of Products to match records by Length:
LayoutTable::Length = Products|Length::Length
And now you need a third that matches by ID's:
LayoutTable::cBinID's = Products|BinIDs::ProductID
cBinID's would be defined as a calculation field with a text result:
If ( IsEmpty ( Length ) ; List ( Products|All::ProductID ) ; List ( Products|Length::ProductID ) )
Your value list, would list Product IDs and Descriptions from Products|BinIDs with "include only related values starting from LayoutTable" specified to limit the list of products via relationship if a length has been selected.
This can also be set up for the Length field so that selecting a bin limits the length options to that bin count by adding yet more occurrences of Products and the needed calculation fields.