(OK, right after posting that I thought of rotating the radio field; it does rotate - and thus aligns the button horizontally - but once you click into it, it gets ugly and rotates the field back to a vertical orientation while you are in the field.)
You can configure radio buttons horizontally. What problem do you encounter when you put the field with the radio button format on the layout and then resize it to be wide enough to list all radio buttons in one horizontal row?
You can even place several copies of your radio button field on your layout and give each copy of the field a different value list--which can enable you to make any number of layout design modifications. The separate copies of the field will still function as a single field and store a single copy of the data.
ne idea I had was to pass in the value of the set as a parameter...
As I have indicated, I'm not convinced that you need this, but you could use the list in that parameter and simple revert the attempted modification by setting the field to the list in the script parameter. No looping is then needed.
I hadn't really tried making it uber-wide to make the text stretch out. A big part of this effort is to create compactness; if I stretch out the field to so that they align horizontally, then it is really wide as the value list is human readable words.
Incorporating part of your second suggestion as I am understanding it (a different value list for each instance) might help that, in that I could shrink the field to hide the text and just have one option. But that is a lot of extra value lists. (Well, more than the minimal needed; might only be 3 I guess, where I am only using 1 now.) That seems like it would also make a lot of clutter on the layout: 3 fields for each row (I have 9 row labels at the moment). Not impossible, and probably not even really a problem, but still... :)
NOW, the last item seems very doable! I obviously hadn't thought of just resetting the field to the original entire list. Doh! I had just gotten it stuck in my head to loop through to find the one that was missing and then re-add that single item. I think that I really like this option. I will do some experimenting with it.
Can you give an example of what you are trying to do and why simply resizing the field doesn't do the job? I can't quite picture what the problem is. If you hide the value portions and just show the radio buttons, how do you know which one to click to input the correct option?
Going with the script and check boxes may work, but I personally would try to avoid that approach for the reasons that I have posted in an earlier discussion: Checkboxes imply to the user that selecting multiple values is possible and acceptible. Radio buttons imply that only one value may be selected.
Here's a screen shot of what I have now. This field is in a pop-up window, with a number of other fields. It is a filtering (i.e. Find) definition interface, to get around FileMaker's built in Find functionality. (This method does expose some additional flexibility that is needed.) With all the fields, and trying to keep the pop-up manageable, a small size is desired. So I am trying to make this compact.
Each column of boxes is defined to a separate field (same name as column header). I didn't want to do it the other way (each row is a field, and the columns are the value list) because then I would end up with a lot of extra fields that didn't seem necessary. And it would still require the UI sheenanigans.
The labels are just text fields; this allows for placing the checkboxes with much greater control. That is why expanding the input fields to show the text isn't desirable.
Each column is actually split up into 2 parts, but each part still points to the same field. The line below the second row is where it is split. The top two have a separate value list for those two checkboxes. I did that so that I could bump the bottom 5 down a bit more and put the line in there; there is a conceptual break between those two groups of fields and I wanted to visually indicate that. And there are two value lists: one for the top half (matching the labels in the top) and one for the bottom (matching the bottom labels).
Yes, I agree, radio buttons would be much better for user intuition, but the limitations(i.e. MY perceived limitations of those objects) preclude using them. There may be ways to get them to work, and I just haven't been able to envision that yet.
I see no reason why you cannot use radio buttons with that layout design. You can resize a field object with a set of radio buttons into a vertical column of just the radio circles and no value text visible.
If all three columns of check boxes in your example are for the same field, you can use three copies of the same field each formatted with a different value list. The radio button format will then make sure that clicking a radio button replaces existing data instead of appending the value entered from the value list to the values already present in the field.
First, each column is a separate field, based on the category label shown at the top. My filter knows how to handle each category type and uses the values in the field to find the real-DB field names.
Let me see if I understand what you are suggesting:
3 radio button sets ( for discussion's sake), with the 3 different value lists. (What would these VLs be?) Each set would be narrowed down to hide the text, however. You mention them all pointing to the same field (which isn't currently how I am doing it).
Wouldn't that setup enforce uniqueness top to bottom, instead of horizontally? I want 'Revisions' to only show up in one column (horizontally), where that column represents the TYPE of search to be performed on that field, with the field name (human-readable) showing up as a list in that field. My script later loops through the 3 types, and each type is populated into the Find records in a specific manner.
Not sure any of that really makes sense.
That's not how I understood your layout design.
First, if the user can only select "may" "must" or "omit" for any given row, then you really only need one field, not three. You can put three copies of the field down on your layout, but in "Display data from" they would all refer to the same field in the same table.
The first copy of the field, would use a single value value list with just: "May" as the value. The second copy's value list would have "Must" as the single value and the third copy would use a value list with "Omit" as its single value.
You can then position and resize these three copies of the same field so that the values are not visible, just the radioi button circles.
Here's a demo file: https://dl.dropbox.com/u/78737945/ColumnedRadioButtonDemo.fp7
I was implying that the field should only be checked in one of the columns, that looking horizontally across the columns there would only be one checkbox. :)
Will download the file and absorb that information.
Thanks for the demo file. I see what you were talking about now. Each label/row has a field to support it. Each radio button uses a single-value value list, with one value list being used for each column. This requires a new radio button set for each and every option (row/column intersection, radio button location). The buttons in the 'May' column all use the 'May' value list, all the ones in the 'Must' column use the 'Must' value list, etc. And since the 3 radio buttons aligned in a row all point to the same underlying field they all interact correctly with each other, i.e. there can only be one selected in that 'group' (the row), even though they are separate layout objects. A group is defined based on the underlying field, not the size (i.e. the number of values in the value list) of the object on the layout.
So, relative to what I had done so far with the checkbox set, this method eliminates the need for a bunch of scripting to run to handle exclusive selections. It does require a lot more objects on the layout, requires more fields (one for each row instead of just one for each column), and more value lists (3 for radio-button instead of the 2 I have for checkboxes...although depending on your UI tastes you might be able to get away with 1 in the checkbox version).
I kind of like the radio-buttons, frankly. The implied UI is more common. Not needing all the scripting is a good thing; although, I would still need to script some verification on the interaction between columns: I want to prompt the user when the 'Undefined' field interacts with the other fields. If they have something as 'Must', then 'Undefined' needs to be omitted (can't be 'May' even) and if 'Undefined' is set to 'Must', then all the other columns must be omitted. I would still need to script the reverting of a selection to a prior state if the user made one of these disallowed choices. Unless the script triggers on a radio-button set will nicely employ 'Exit Script [Result: 0]' to essentially negate the user's choice.
But the additional architecture is...against my inner instincts. Not that I can say that this additional architecture would ever lead to performance issues, it is just a tendency to try and avoid clutter (or perceived clutter). To scale radio-buttons up you need a new field for each new row item, whereas with the checkbox columns I only need the 3 fields regardless of how many rows I want to add. My value list would increase in options, but that isn't a problem. For the layout a new option would require a new layout object for each column involved.
There are probably other aspects I haven't thought of. This discussion doesn't necessarily bring me to a decision, either. :)
The extra fields was a guess on my part as to your original layout design/data model.
The same results can be produced if you make each row a separate record in a related table instead of a group of individual fields in the same record.
I thought about creating a single field that would contain the search parameters as as value sets: <HumanName>|<DBFieldToSearch>|<searchValue>.
How would you use related records in another table? Would require a portal and relationship I am guessing. Is there some way to do it with ESQL perhaps?
Yes it would require a portal and a relationship.
No, I do not see a way to do with with ExecuteSQL as ExecuteSQL would be used in a calculation field and you can't use that for data entry.
whether there is any advantage to using a portal instead of a list of individual fields depends on how you need to work with this group of fields. A portal enables you to show/work with variable numbers of fields. I don't really know if that is the case here or not.
Phil, is this (below) a fair summary of your suggestions? It sounded like you threw in some extra fields that might not be needed, but I am not quite seeing what fields were 'extra'.
** Radio buttons:
Fields: 9 - One field for each row (row=field for scaling)
Scripts: 1 - Maintenance to check for Omit entries
Value Lists: 3 - one for each column
Layout: 27 objects (3 columns, 9 fields)
Filter script has to process 9 fields, checking content of each to find out what type it is. Could create array of field names at the top and loop through that; would have to loop through it 3 times, once for each category, populating the Find records for that type.
Fields: 3 - one for each column (which corresponds to a search type; scaling is easy - add entries to existing Value List)
Scripts: 2 - 1 to enforce the radio-button-like functionality of only one column selectable at a time, 1 to check for Omit entries
Value Lists: 2 (in my current version), so that I can physically separate the row labels visually. (Maybe a third for Dates?)
Layout: 6 objects (3 columns, 2 groups)
Filter script has to process 3 fields, populating FIND records based on each type (fairly straight foward)