Hello,

I have about 15 "Categories" that are set up in a value list check boxes. I would like to create a layout that only shows the text of the "Checked" boxes.

Can someone please help!

Thanks

Dave

Hi Dave, welcome to FM Forums!

Are you saying that you have 15 'like' fields which are all named a different category and each has a checkbox attached which produces a 1? Or does each field have a different custom value list attached, one for each different 'category?' We need a bit more information, such as the table name, field(s) involved, values defined for the checkbox. Also, where do you wish to display the 'text of the checked boxes'? Is this for a report or for viewing in browse mode while scrolling (what type) of records?

Thanks,

it is a Checkbox set, some of the values are:

Test 1

Test 2

Test 3

Test 4

Records will have one or more of these checked off, I would only like to List the test i.e Test 1, Test 4 (if those are checked) I would like to include this in a report, (only the ones that are checked) it will be in a printed report, does this help? the name of the Value list is Shot Types and the name of the Checkbox set is shot types as well.

Thanks

The field itself (ShotTypes), if displayed as edit instead of with checkbox attached, will display only the selected items per record - as a multiline list. If you wish to display it instead like a single line separated with comma, you can create calculation (result is text) with:

Substitute ( yourTable::ShotType ; ¶ ; ", " )

Perfect!! It works Great!!

Thanks! NEW FAVORITE FORUM!

Thanks,

it is a Checkbox set, some of the values are:

Test 1

Test 2

Test 3

Test 4

I made you a quick demo and then saw that LaRetta had posted calc, so I changed the file to show a little different way you could do this

Lee

CkBoxTextField.fp7.zip

Dave,

I have to chime in with my usual warning. Checkbox sets are easy to implement but often lead to reporting difficulties. It might be better to have a related child table of Categories. Even better, you have a join table between your parent record and the Categories table. This'll give you consistency and accurate reporting.

hth,

Barbara

PS: Just posted a demo for another person who's realized the limits of checkbox sets.

If you are going to warn against checkboxes, Barbara, it helps to explain why.

Hi Dave,

There is nothing wrong with checkboxes, multilines or arrays and we use them all the time. It is also easy to switch checkbox to related table later if one is needed. When not to use a checkbox:

1. If you will need to summarize by each value for reporting purposes
   
2. If there is more than one *fact involved
   

For #1 (reporting) and you have a checkbox called Interests as:

Sky Diving

Surfing

Mountain Climbing

... and you need a report as:

Sky Diving - Total 3

Joe Smith

Mary Andersen

David Rowe

Surfing - Total 2

Joe Smith

Nancy Jones

... etc

For #2 (more than one fact) and you want to also track who checked each item and the date they checked it (for example). It is true that you can still store more than one fact in a field (even multiline) as:

UPS Ground|UserA|1/30/2012

Pick Up|UserB|1/31/2012

... but it will also make reporting impossible. Checkboxes are perfect to use in other instances. When you responded in Post #3 with:

"some of the values are:

Test 1

Test 2

Test 3"

... it did not strike me as a reportable (summarized) need. But I am glad that Barbara brought it up; I should have verified.

Also, if you store TypeID rather than Type, you can change the Type Description without orphaning existing data. But yes, I find one "outgrows" checkbox sets quickly. Ask yourself, "will I want to report by this?" If so, I suggest a join table.