You can set the width of a tab label to zero, but you cannot change the height. And you can't let the control touch or cross the boundary between header or footter either...
I can't think of any other approach for this short of creating layouts that are duplicates of each other except for the checkboxes.
Well that's too bad. Oh well. I will see if I can make it look right with these giants. :)
Hmmm, if your different checkbox sets are all for entering data in the same field, but from different lists of values, a conditional value list might be used and that would eliminate the need for your tab control.
No, I am essentially recreating a flat table: user names down the left (the list view) and objects to assign them to across the top. It is a simple boolean assignment: yes/no.
There are a lot of objects, though, so I wanted to divide them up into chunks and keep the layout from becoming a huge horizontal mess. Hence the tabs. I scripted the tabs at the top (in the header) to switch the tabs in the body list view to correspond to the fields they are being assigned to for that category. I.e. it shows the checkboxes that correspond to whatever tab in the top is selected.
The copy script was all about then taking those boolean assigments and essentially generating a list of emails for a particular list, copy those emails to the clipboard so that the user could then paste them into a web form.
and objects to assign them to across the top. It is a simple boolean assignment: yes/no.
And each tab displays a different set of single check box fields?
This still feels like something you could do with a single field with a group of checkboxes. A conditional value list used with this field can change the group of boxes displayed on each record and auto-enter calcualtions can then reference the single field to extract specific values from it should that be necessary.
The result on your screen can look like this:
John [x] apple [ ] kiwi [x] carrot
Fred [ ] apricot [x] plum
Jim [ ] prune [x] plum
But I can see a drawback to this idea given that the check boxes won't be aligned in neat columns...
I believe that you know what I mean, but I am not quite getting what you mean, so I will reiterate my task just in case. :)
Each person has the same options, so I don't think that I need to have a conditional list (unless I am misunderstanding where you envision it being applied). It is just a giant Excel sheet: 30+ options across the top (possible things to assign them to), and the users down the side. You go through and check off each person as yes/no to being assigned to that item. Then there are supporting scripts to generate a list of emails of those people that ARE assigned to an item, and that list gets copied to the user's clipboard.
My table has 30+ fields (one for each item to assign them to, plus a few admin and functionality fields), and then 1 record for each user.
In order to make the layout more compatc, I broke up the 30 items into categories and put those items on different tabs. This will probably be an interface that is only used by 1 or 2 admin type folks, it isn't intended for the general users.
My table has 30+ fields (one for each item to assign them to
Hmmm, I'd take a real careful look at that part of the data were I you. It may be possible to set up a related table for those 30+ fields. I could still get that data organized into columns using one row filtered portals to the related table.
Thanks for the ongoing suggestions. But I am still missing something; not quite grokking what your suggestions are. Could you explain them more fully?
We're a bit "disjointed" here because I still don't have a clear picture of exctly what you are doing. I've tossed out some general suggestions here that may or may not work for you as the devil is in the details.
It's basically a good habit to get into any time you find that you have defined a large number of fields (30+) that all have a similar function. That may well be the best design approach, but since there are ways to set up a related table where you have one related record for each field--producing 30+ related records in place of 30+ fields, it's a good idea to consider that option as it may offer advantages not possible/practical with the 30+ individual fields.