Overriding portal field styles?

[kfutter]

I've got a portal set up that is inheriting the text colours from the related fields I'm dislaying. Resetting the portal field's text colour doesn't work - the text format for the field says it's already black (rather than colour-coded like the corresponding fields in the related file). Is there any way of overriding this without changing the related field's text formatting?

Kevin

[comment]

It looks like your actual data is formatted with color - nothing to do with field formatting.

[kfutter]

That doesn't make sense to me - data is data, colour is formatting. It's my understanding that raw field data - like that available at the XML interface - only contains raw data values (ASCII/Unicode or binary), and formatting is *always* another layer on top.

I got around it in the end by creating new calculation fields in the related file that strip out the formatting, and using those instead. Of course, now I've created the problem that those fields are no longer editable via the portal. Oh well. Normally I wouldn't worry about the coloured field data, but this particular portal needs to be printed.

Kevin

[Vaughan]

"That doesn't make sense to me - data is data, colour is formatting. It's my understanding that raw field data - like that available at the XML interface - only contains raw data values (ASCII/Unicode or binary), and formatting is *always* another layer on top."

Agreed... except people wanted the FMP calc engine to honor data formatting, so the calc result retains the original data formatting.

We got what we asked for. ;-)

The ideal situation is to strip the colour out of the original data (using the Text Formatting functions) and format the layout field objects to display the colour -- thus leaving the data unformatted.

The auto-enter calculation option is great for stripping out text formatting and removing leading and trailing white space at data entry time.

[kfutter]

I see - interesting. Unfortunately for me the data in the related database is the victim of the original developer's desire to have users colour-code various entries based on category. Users highlight the field text and select a colour from the picker. Eventually I'll get around to replacing this with a series of colour-coding buttons that apply the appropriate colour when clicked, but I'm not sure if this produces the desired result viz how the formatting is applied.

Kevin

[Lee Smith]

Kevin,

use the Replace and the TextFormatRemove ( text ). No more color.

Lee

[kfutter]

Thanks Lee, but a question for you: does that affect the original field, or only the portal view? The original fields need to retain their coloured text, but I need to remove the colours in the portal view in another file.

Kevin

[Lee Smith]

Yes, it will change the original field. However, you can use a calculation of the original field, and print from it.

Use a copy of your fields, make them a calculation that equals the original field

c_fieldOne (calc, result same as the original) =

TextFormatRemove ( FieldOne )

HTH

Lee

[comment]

Of course, now I've created the problem that those fields are no longer editable via the portal. Oh well. Normally I wouldn't worry about the coloured field data, but this particular portal needs to be printed.

You could use another layout for printing. But the true solution is to move the information into a dedicated category field, so that text color can be removed permanently at the data level. Perhaps this custom function can help you with that.

[kfutter]

Yes, it will change the original field. However, you can use a calculation of the original field, and print from it.

Use a copy of your fields, make them a calculation that equals the original field

c_fieldOne (calc, result same as the original) =

TextFormatRemove ( FieldOne )

HTH

Lee

That's pretty much what I've already done. I now understand what the respondent further up meant about the formatting applying to the data - I just had a conceptual block with that one. I don't think I have any other choice at this stage.

Kevin

[kfutter]

Unfortunately the field holds calendar event descriptions that need to be colour-coded as one of a dozen or so categories, and I can't see how else you would manage it other than changing the format of the actual data. Bear in mind that I wasn't involved with the development of either database in play here, but I do plan to at least automate the colour-coding at some point.

Kevin

Edited April 23, 2007 by Guest

[comment]

I am not sure I understand that. I would have a category field (text), where the user would select "one of a dozen or so categories", using a drop-down menu or a radio button. Then the color coding would be a calculation - instead of the other way around, as it seems to be now.

The color-coded calc field, with entry to field disabled, could be overlaid on top of the real description field. This way users can see the colors as they browse, but when they click to edit, they enter the real (non-colored) field.

[kfutter]

Wouldn't the non-editable calc field block access to the editable field underneath? I haven't tried this, so I'm just guessing.

I plan to use a grid of buttons, labelled and coloured to match the categories in question, to which I attach a script. The button passes the category in question as a parameter to the script, which then applies the appropriate formatting. I guess the difference is that I'd still be changing the actual data formatting.

To be honest I'm not a fan of colour-coding as a means of conveying information, particularly with a dozen levels of differentiation, but that's the system I've inherited.

Thanks everyone for your help and suggestions.

Kevin

[comment]

Wouldn't the non-editable calc field block access to the editable field underneath?

No.

The button passes the category in question as a parameter to the script, which then applies the appropriate formatting. I guess the difference is that I'd still be changing the actual data formatting.

The script should set the category field to the selected category (same as picking the category from a value list). The formatting can then be calculated in a separate calculation field - leaving the real data unformatted.

To be honest I'm not a fan of colour-coding as a means of conveying information

There's nothing inherently wrong in conveying information in color-codes. But information should NOT be stored there.

[kfutter]

The script should set the category field to the selected category (same as picking the category from a value list). The formatting can then be calculated in a separate calculation field - leaving the real data unformatted.

The problem is that there is no 'category field' - just a field for event descriptions. I understand that you're suggesting I add those fields, but for my problem a more expedient solution turned out to be creating a calculation field that stripped the text formatting, and using that for the portal. Sure, not as clean or semantically pure from an architectural point of view, but fewer changes to the database, which is always a plus on a live data source that has a whole raft of other issues as well!

There's nothing inherently wrong in conveying information in color-codes.

There is if your users are colour-blind, or have poor visual acuity, or if you haven't provided sufficient contrast between text and background colours, or between the different colours themselves, and I certainly think that distinguishing more than 2 or 3 different meanings based on colour alone is fraught with danger.

Kevin

Edited April 24, 2007 by Guest

[comment]

The problem is that there is no 'category field' - just a field for event descriptions. I understand that your suggesting I add those fields, but for my problem a more expedient solution turned out to be creating a calculation field that stripped the text formatting

That is at best a band-aid, not a solution. How would you, for example, find all records in a given category?

Color-coding is widely used in many applications, e.g. electronic components ratings. But I didn't mean to argue in its favor, but rather to stress the other point - that storing information in the form of text formatting is severely limiting your ability to use this information. To give another example: how would you add another type of display, one that is suitable for color-blind users?

[kfutter]

The truth is, I think the entire concept of categories for this particular database is superfluous and somewhat gratuitous. Many people using the database ignore them (and their colour-coding) altogether, and nobody uses them to organise its data.

Personally I agree with your approach however, and would probably implement something similar if I were starting over. There is some politics involved there though, since most of the databases we currently use (including those under discussion here) were developed by an enthusiastic but limited amateur (our College principal), who still likes to 'keep his hand in'. Sigh.

[comment]

Well, if the principal is enthusiastic, suggest he/she joins this forum...

In any case, I think converting the system from color being input to color being output shouldn't take more than a couple of hours - depending on how consistent the colors are.

[kfutter]

Well, if the principal is enthusiastic, suggest he/she joins this forum...

In any case, I think converting the system from color being input to color being output shouldn't take more than a couple of hours - depending on how consistent the colors are.

Unfortunately I have several dozen other (more pressing) things I need to spend that couple of hours on, so it just doesn't register that high on the priority scale. There are only 3 of us to manage the entire IT infrastructure and services of a large school (network, servers, computer labs, databases, websites, staff training, etc etc), so as you can imagine, tinkering with FileMaker all day is just not an option.

Kevin