I think you are going to have to use separate layouts––one Form and one Table.
Allen is correct, you would have to do two layouts. You can have a button to toggle between them. Usually the table view is just for quick and dirty work and if you want to make things smooth and elegant, you do it in list view where you have full control of such options. But of course you can't drag fields around and resize them, etc., in list view.
Speaking of check boxes, the FM check boxes just suck. So I usually have to make my own graphics or a button that I alternate hiding the check and unchecked state so that it looks good in the user interface. Boy I hope they improve them someday. They just look so 90's-ish.
Do both versions of the field (text box and check box) have to be modifiable in both Browse and Find modes?
Thanks, all, for your thoughts. Shorter answer to Richard's question: I want these to be editable:
In FORM view
Checkbox in Browse mode - yes
Checkbox in Find mode - yes
Textbox in Browse mode - preferably, yes
Textbox in Find mode - preferably, yes. (Tho I can do Finds using a calculated "TagsOn1line" field which concatenates 2 checkboxes and a CSV free-form tags field.)
In TABLE view
Checkboxes in Table View are useless: Too many values take up too much space.
Textbox in Browse mode - preferably, yes
Textbox in Find mode - preferably, yes. (Eg, to search for "book" See below)
Longer answer / explanation: Data entry and editing is done almost solely with the checkboxes in Form View.
The main exception has occurred because I've made changes to the table structure and value lists, and some values (eg, "book") have been pulled from the Subcategories field and placed into a new Media field. If an older record still has "book" as a Subcats entry, that fact will not be visible (with the checkbox in form view) b/c "book" no longer appears among the checkbox options for Subcat. With a textbox in FormView, however, I can Find, see, and update such entries.
(Aha! - I bet I can use "Validate Always" to quickly ID those records that contain values that are no longer in my values list. Yes? I've never tried that.)
I doubt FM uses a random number generator to decide which of the two (a textbox or checkbox control from layout mode) is the one that appears in Table view. It'd be nice to know the algorithm and be able to control the outcome. But maybe I use "quick and dirty" a lot more that some folks. I imagine I'll be taking taking the "2nd layout" route. But it's a situation I face more than occasionally -- it'd be nice if the 2nd layout weren't necessary. Again, thanks all.
I don't know what algorithm FileMaker uses to determine which is the "main" occurrence of a field if it appears more than once on a layout, but I DO know that, in the Relationships diagram, the first table occurrence (TO) created is the one that the calculation dialog defaults to, so I'm guessing that the same might hold true here.
If you're willing to experiment, try this. Remove ALL occurrences of the desired fields from your layout. Nip back into Browse mode. (This may be superstitious behavior on my part, but I think that switching out of Layout is sort of like "Commit Records", except that it nails down the layout changes instead of the data changes.) Then go back into Layout mode and insert the desired field, formatted as a text box (since that's the version you're going to need in both Table and Form view). Go into Browse / Table view and make a note of where it occurs. Then back into Layout and add the field again, this time formatted as checkboxes. My guess is that this 2nd occurrence will be the disfavored version of the field in Table view and thus not visible, but go back into Browse / Table view and see if I've guessed right. If I have, then your Table view will be copacetic, and you can rearrange your Form view to your heart's content.
Hey hey!! It worked. BUT ... when I moved the text boxes BELOW the checkboxes, the fields became checkboxes in Table View. Fortunately, when I moved the text boxes back ABOVE, they returned to text boxes in Table View. So my current hypothesis is:
1) Create the Text boxes FIRST (as you suggested), and 2) then the checkboxes, and 3) keep the text boxes ABOVE the checkboxes. I'll let you know if this formulation proves inadequate.
(BTW: Visiting Browse mode between steps 1 and 2 was NOT necessary, nor was creating the checkboxes to the Right of the text boxes ... at least in my single test of these.)
Really appreciate your help!