Has anyone found a way around fields with a value list set as a checkbox set conforms to the standard behaviour when a layout has been set to 'Delineate fields on current record only'?
As soon as a field is changed from 'Edit' to 'Checkbox set' the behaviour changes and it behaves as if the delineate setting hasn't been set in 'Layout Setup'. I haven't investigated conditional formatting or hide as yet, which seems a very convoluted way of trying to achieve a standard behaviour.
what do you want to achieve? A checkbox by definition should show a box?!
Or are you thinking of the background of the box? That could be turned off to not distract in a list as shown in your screenshot. But it doesn't get highlighted when the record is activated. Seems to be at least a glitch in UI consistency.
Good question, upon rereading my post, I haven't made it clear.
In the example screen image shown, the figures to the right have a white background, but the only time the backgrounds are shown is when the record is active, as shown in the middle record in the list. For the rest of the time we have data displayed on fields with transparent backgrounds with a layout alternative background making it easy to trace the data along a record in what is quite a wide layout. We use a white background for fields that are editable and transparent for those that are not.
Hence, a user can scan view the list, easily view the data and, when they click on a record, it shows which fields are editable. Without the delineate setting, all the white backgrounds are shown all the time and it looks pretty awful, we couldn't stick to our editable/not-editable formatting. I can't provide larger screen images as I'm working on client data, but I have attached a screen shot with the checkbox field converted to a drop down list, which is how we want it to look (both checkbox and radio buttons break the delineate setting)
However, the minute a field is converted from an edit field to a checkbox set field the behaviour changes and the white background is permanently displayed. Change it back to an edit field and it reverts to standard behaviour.
Hopefully, the above makes it clearer (I feel yet another work around to compensate for erratic behaviour coming)
I may need to play around with conditional formatting, or just give up or use a drop down field instead, but as we've legacy data in this, that would be awkward.
Otherwise, I'll have to put up with a substandard layout appearance. It is these small issues that have probably been there for years I wish Claris would clear up rather than constantly push forward. Traditional layout design is a pretty thankless task these days, no sliding or reduction of part size in non-body parts, etc.
....
and no sliding or reduction in browse-mode which would make list views or portals look really professional, but we are way behind other rendering tech like HTML etc.
Times too short, I'll live with the checkbox field with a permanent transparent background as per attached. It affects output and isn't a true data entry field, but it is editable.
It is so frustrating when technology from who knows how many years back still comes back to haunt us on a daily basis.
We don’t use check boxes and radio buttons. We use scripts and buttons. Yes stupid given that the check boxes and radios exist but we get better control of these behaviours
