Assuming your browser window is wide enough, the 'what I need' should display as 4 rows with 3 columns in each row.
Thanks for any help you can lend.
-- k --
Change your actual value list of 11 elements to 3 value list, one for the values of each column.
Than place on the layout 3 occurrences of the same field, but each one formatted to show the values of a single different value list.
Do I presume correctly that you've got, here, a single field (let's call it "healthIssues"), a value list with 11 options, and a checkbox-set format so that users can select more than 1 value? If so, then the underlying problem is one of data schema design; get that right and the UI problem will take care of itself ("form follows function").
What I mean is that multi-valued fields such as this are an undeserable way to store information: in a relational database, each field should hold a single, atomic value. It's referred to as "first normal form" and is really the most fundamental rule of all when designing your schema. So, moving from theory to practice, what you need to do is create 11 fields ("hasAcutePain," "hasAlteredStatus," "needsHospiceAssessment," etc.), each one Boolean (accepting only 0/False or 1/True as values). Your value list, then, has only the single value "1" and is used for each of the 11 fields.
On your layout, format each field as a Checkbox Set using this same value list, and line them up as desired. Not only will you be able to line things up (a minor side effect) but, more fundamentally, things like querying, sorting, reporting, etc. become much easier and more rational. There's a reason that first normal form was there at the birth of the relational model. ;-)
BTW, although FileMaker lacks a true Boolean field type, there are several ways to restrict a field to Boolean values. My favored approach is to set two Auto-Enter conditions on a Number-type field: (1) Data [=0] and (2) Calculated Value [=GetAsBoolean ( Self ), uncheck "Do not replace existing value of field (if any)"]. That way, the field defaults to 0/False, rather than null, and can then be toggled between 0 and 1 with the checkbox control.
Your suggestion means exchanging a flawed design with a slightly less flawed one. What happens when the list of (let's call them) “health issues” entries grows? Create more fields and matching summary fields?
k… should instead create a related table that holds as many “healt issues” records as necessary.
That will indeed make
Mark Scott wrote:
things like querying, sorting, reporting, etc. […] much easier and more rational.
If something like a checkbox UI is desired, let's create a HealthIssues table and present several portals into a Cartesian relationship, where checking/unchecking means creating/deleting related records (in what now has been promoted from a child to a join table).
All this with the caveat that the learning curve will be steeper, since now things must/should be scripted.
I believe this is an issue when using WebDirect.
I agree with you, although I think this could be a case on the boundary between these approaches, depending on whether the list of possible health issues is open ended (i.e., might grow) or is of the ol' "collectively exhaustive and mutually exclusive" variety. I could probably go either way here, knowing that reporting would potentially be more difficult by splitting these off into a related table. Normal form issues don't always get resolved by splitting tables (with the exception of a pure EAV model, I suppose). "Person --> phoneNumber1, phoneNumber2 . . . phoneNumberN" would clearly cry out for a 1:M table split; "Person --> firstName, middleName, lastName" probably not (except in EAV); and this case somewhere in between.
Another example of something that could swing depending on open-endedness: in a database of measurements for fitting eyeware, interpupillary distance, intercanthal distance, etc. would probably just be attributes/fields in a "Patient" table — even though they share a common domain (mm), they comprise an essentially closed list — whereas in a more comprehensive biometrics database, I'd certainly split the much larger (and potentially time-varying) list of measurements (possibly including interpupillary distance, etc.) into a "Measurement" table.
That said, now that I look back at Ken's list, I'm seeing something likely to be more open-ended than he initially let on, so I'll vote along with you in favor of a 1:M split.
Thanks Mark and all who responded -
I agree that normalization allowing for discrete values would be the better way to build the schema. Only 2 issues with that: 1) the tables were created by another person in the past and 2) the list can/will grow and change. Conversion of the external SQL database would be difficult at best since previous data exists and values have changed. Current reporting also utilizes SQL 'in' for selection of the desired values so reporting changes would also be necessary.
Keywords - yes, the checkbox list is displaying values from a reference table as a value list. The reference table is a MS SQL table with a defined relationship. Do you have a specific style defined in your form for checkboxes ?
Thanks again for everyones input
If this is a WebDirect question, then I showed with my CSS hack for WD how to force align checkboxes. I think you could modify it from being a single column like I demo into being a static width so everything lines up in multiple columns.
Thanks, Ken, for chiming back in with the additional info. A growing/changing list makes erolst's suggestion all the more "the right way" to do this, but I also appreciate the constraints you're under with a legacy system and integration with a SQL Server database.
One idea — with the usual potpourri of pros and cons:
Use buttons with "checked" and "unchecked" checkbox graphics, in lieu of fields with checkbox-set formatting, to toggle individual values "yes" or "no" (or, if you do end up migrating to a 1:M design, to create/delete child records).
this long-standing technique got a lot easier in FM12 (with image fills for buttons, including slicing to keep the checkbox graphic to the left) and FM13 (with "Hide object when…" to hide the "checked" state graphic as needed, as well as padding, to adjust the left edge of the label to sit to the right of the graphic);
can precisely control both the checkbox appearance and their placement on your layout to your heart's content.
adds extra weight in the form of more CSS (or local formatting, although saving the local formatting as a style is generally preferred), which can impact performance in hosted solutions, including Web Direct*;
extra work (albeit not a whole lot) when FM already has a "perfectly good" checkbox-set field control.
(*Someone mentioned Web Direct; I don't think you said it was WD, unless I missed it. Sorry, with 1 hour sleep last night, my reading comprehension is kinda crappy this morning. ;-)
Be inerested to hear how you tackle the alignment issue.
If you think about using checkbox image, there are chars for them.