font color/picture changing based on condition?

[jsutherlin]

Does anyone know if it is possible to change to color of a font or what image is placed based on a condition that is evaluated in a script or in a field calculation. Say if the particular calculation = 1 then the font is red or red picture is placed, 2 the font is blue or bluepicture is placed, etc. If this isn't possible within FMPro maybe a plug in.

Thanks.

[John Caballero]

I don't think changing font color is possible in FMP, but you can certainly create a highlite color that changes depending on the value of a field. The same applies for different pictures. This has been discussed recently.

Here's the basic idea - in a seperate table (a graphics table), use the rectangle tool to draw a few rectangles and fill them with different colors. You can either use a repeating container field or seperate container fields (my preference) into which you'll paste your colored rectangles. In each table, have a calculation that returns a constant value ("1" works like a champ). Create a relationship from your main table to your graphic table that is based on the constant fields in each table. Create a container calculation in your main table that evaluates the value in some field and returns different container fields from your graphic table based on the target field's value.

It should look something like this:

Case(

Somefield=1, graphics::container1

Somefield=2, graphics::container2,

Somefield=3, graphics::container3,

"")

You'll want to have your target field superimposed over the top of your calculated container field so that the container field acts as a highlite color.

Hope this helps.

[Ugo DI LUCA]

Hi,

Nowithstanding John suggestion, if the text could be fixed and calculated, then you could simply use several calculation fields, overlapping eachother, each being in a different color or font, or style.

i.e.

n_fontcontrol (number value)

0 for Arial, 1 for Verdana, 2 for Helvetica

c_returnArial = Choose(n_fontcontrol,yourtext,"") - format as Arial

c_returnVerdana = Choose(n_fontcontrol,"",yourtext) - format as Verdana

c_returnHelvetica = Choose(n_fontcontrol,"","",yourtext) - format as Helvetica

[John Caballero]

Way cool idea, Ugo! I've never understood why FMP doesn't let us change text color based on field values.

[ESpringer]

Bandaid solution for text color change: create a field with a calculation to display the value ONLY IF it's negative (say), and then superimpose the negative version of the field (with transparent background to field, using the same font, but this time in red (say)) on top of the original.

Or, to parcel the value out into as many mutually exclusive variants of the field as necessary with separate calculated fields, and display them all in different ways (now you can change font or style, too) but again all superimposed on the layout. Obviously, it won't work for table view, though... Nor will johncaballero's nice background color/picture solution, very handy IMO.

[Ugo DI LUCA]

How does this one differs from what I suggested ?

You can change font, color, size, style using the same approach.

It still is calculated though, while John's allows the text below the highlight to be edited.

Am I missing something ?

[LaRetta]

jsutherin said...Say if the particular calculation = 1 then the font is red or red picture is placed, 2 the font is blue or bluepicture is placed.

You haven't said whether the font you wish to display is a field or straight text combined with a graphic!? You've been given ideas about coloring a field's font by stacking, highlighting a field's background and also placing a graphic in a container and having a graphic appear. But you can also have regular text and a graphic appear together in a container. And each message can be stored in the same global (container) in multiple reps.

Combining text with graphics is a great way to draw a User's attention. You can 'walk' them through complex data-entries by directing their eye by using a message with arrows, for instance and it is much more User-friendly than validation message boxes. It's a great tool (if not overdone and where appropriate).

Even embossed or engraved (stacked 3D) text can be combined with a graphic and pasted into a global container (hold shift and select them both), and the text displays (and maintains) the 3D effect beautifully. The only limit is your imagination.

How to store text/graphics in a global container:

Create a global container (gMessage) and select 2 reps. Place this field on a layout, go to field format & change reps to display 2. In Browse mode, paste your red text w/graphic in rep 1 and your blue in rep 2. Then delete gMessage. It won't be needed again unless you change your messages. Create an unstored Case() calculation (container) with:

Case(NumberField = 1, GetRepetition(gMessage, 1), GetRepetition(gMessage, 2))

Interacting with the User in this way can be quite effective. Oh, so many options with FM.

LaRetta

[ESpringer]

Ugo,

I didn't follow your suggestion right away (didn't know you could get a calculation to include font info), and wrote my post while contemplating that one... but I think the difference is as you suggested: that multiple stacked variations on the same field (like background graphic/highlighting) can allow a primary version (the bottom in the stack, if its text color being manipulated) to remain live for data-entry, so the user can interact as if it's simply conditional formatting on a standard field.

-ESpringer

[Ugo DI LUCA]

Ok, I get it now. Format a calc or keep the original....and you can still use it.

BTW, mine doesn't interact with fonts. The calcs would be formated differently while in layout mode. And the fields need to be transparent background too.

Then if it's 1, the calc formated with Verdana would show, all others won't.

That's all.

[BobWeaver]

Another option:

Rather than overlaying the results of the calculations, you can stick them all together in a merge field like so:

<<c_returnArial >><<c_returnVerdana >><<c_returnHelvetica>>

And format each part appropriately.

[ESpringer]

Many solutions here--each with advantages depending on who designs it for what situation.

Thanks to LaRetta, I've figured out how, in a bibliographic database, to make my birds-eye layout (with ALL input fields) friendly and usable: the fact that many fields are irrelevant to any given record is not distracting if behind the fields (all transparent) there's one calculated container that responds to the input of reference type (book, article, chapter, etc.) and underlays a set of colors and boxes and text that draws attention to the relevant fields to fill, while leaving the rest in low-contrast obscurity. Thanks! It's like a virtual layout change, better than multiple layouts, because simple record navigation is automatically accompanied by the right shifts in color/box emphasis.

By the way, OmniGraffle does a great job with editing tasteful gradient graphics, floating shadow boxes, flow-chart-style boxes and lines... highly recommended.

[LaRetta]

Hi ESpringer!

Thanks for the recommendation of OmniGraffle. I've downloaded it and can't wait to play with it.

User-friendly designs are certainly my hot button! BTW, I'm currently finishing a demo for a total mouse-driven Order LineItem screen, where each section appears as needed (through invisible portals) - and the list of products (instead of 100 displaying in a list) are filtered. It's exactly as you describe it - and as it should be. If Users are confused or strained because of a full page of crammed fields and data, things get overlooked, it depletes their energy, and slows them down.

Having said that, and to show a simple comparison ... I've attached a real, honest (no lie) Act database that is currently being used. 9 Sales persons HATE it - you'll see why. They need to scroll almost 3 pages wide to see it all. Imagine looking at that for eight hours a day!! Their replacement design is forthcoming.

User-unfriendly database

LaRetta

[ESpringer]

Ugh, I don't think I've ever seen anything so garish in my life!!!

That belongs on a last-prize-ribbon page of useful bad examples.

Well, they sure went from one extreme of the GUI-spectrum to the other in seeking your help!

Perhaps you've had some ideas about how portals and fields can be closer to "invisible" when not needed -- I'm irked by the dotted/grey outline that insists on popping up around every field when any of them are accessed for data entry... Is there any way to make that less obvious? (It means, of course, that covering or underlaying an irrelevant field with an optional graphic, for example, works until the user interacts with things on the layout, and then all of the sudden the body-background color fills all the field rectangles... : <

I'm eager to hear your reactions to OmniGraffle...

[LaRetta]

Well, in all fairness to the designer, s/he was faced with urban-sprawl over a six-year period - as we all understand, I'm sure. And Users kept getting lost, so s/he coloured the fields to make them stand out! Then Users would miss other important fields, so s/he coloured them, etc.

Perhaps you've had some ideas about how portals and fields can be closer to "invisible" when not needed...

Actually, that's exactly what I'm finishing this weekend - Instead of hiding portals and fields by overlaying with calcs, all fields and buttons appear (many in portals) only when needed. And messages direct the User through the process. It takes only 45 seconds to add all LineItems to an order instead of the usual 9 minutes using ala Act or 75 seconds using a standard portal LineItem design. And it requires no training or direction whatsoever. Even my mother (whom I use to test everything because she knows nothing about computers) completed the same order in 53 seconds and she was very nervous.

I'll have the demo finished tomorrow and I'll share it. And maybe we can compare notes on OmniGraffle once I've studied it - it looks very, very promising! Thanks again.

LaRetta

[ESpringer]

Well, that's very charitable of you... and of course it does remind me of my first complex databases -- constantly living in a house under construction -- only more so. ; )

I'll look forward to seeing what you mean about having things appear only when needed. It sounds four steps beyond what would occur to me to attempt...

Cheers.

-ESpringer

[LaRetta]

ESpringer said...It sounds four steps beyond what would occur to me to attempt...

I doubt that! I'm not that good at code - math is a major weakness.

Please ESpringer (and anyone), feed me some of your designs (or graphics) - I can't learn enough about it to satisfy myself - and examples of what you've done to make life easier (or more visually workable) during the User experience would be divine.

LaRetta

[LaRetta]

Oh ESpringer, my apologies for missing one of your questions!

lirked by the dotted/grey outline that insists on popping up around every field when any of them are accessed for data entry... Is there any way to make that less obvious?

Set all fields that you don't want to show dotted lines through field format to not 'Allow Entry.' Then attach a script to each field with Go To Field[ThatField]. Users can no longer tab to them however and must click into them.

And create a regular script. I've made the mistake of using Show Button for this 'seemingly' simple script-step and it won't GO, under the FM theory that Users can access the Show Button 'script-like' scripts. I think it's poor reasoning on their part!!

Hey Stephen! Here's one that might be a Sticky Topic!

LaRetta

[John Caballero]

BobWeaver said:

Another option:

Rather than overlaying the results of the calculations, you can stick them all together in a merge field like so:

<<c_returnArial >><<c_returnVerdana >><<c_returnHelvetica>>

And format each part appropriately.

Hi Bob,

I'm intriguied by this approach. Can you provide a sample?

Thanks!

[LaRetta]

Hi John,

I was tickled to see Bob making this suggestion also. I keep forgetting that merge fields can be formatted individually within the merge.

If you select (highlight) anything between the <> and also grab the <>, you can then apply field format (color, size, font, etc.) on just that portion of the line. So, if it's something that you can use a merge field on, it's the way to go for sure!

LaRetta

[ESpringer]

A real advantage of that method (using a string of merged text, with <<variant field1>> and then <<variant field2>> standing in line with different formatting, is that if you perpetually develop your databases (as I do ; ) ) it's much easier to flip into layout mode and tweak, rather than digging to the bottom of a stack of similar fields.

Well, perhaps I should inquire of those with more experience: does FileMaker have a way to select (in layout mode) specifically what's NOT on top, or to figure out what's on top without trial and error experiments of dragging one or more "layers" away, only to discover the one left on top is still not the field or graphic intended? I've noticed that one can use "tab" to move among the elements in a layout, but something like a palette with a specification of the nature of the object currently selected (as in OmniGraffle and Macromedia, among other things) would be nice!

[LaRetta]

Hi ESpringer!

Well, there are probably other ideas but I've recently discovered the power of using Arrange > Lock. For instance, when I'm trying to grab and group certain objects, sometimes it's difficult to work. So I lock the objects around that I don't want to work with. Don't worry if it tells you can't modify them because you don't want to anyway. Just make your changes and they won't change or move - but what you want to change ... will!

What I've done to is grab the large items - or, in your case, the things on top and lock them. Then group drag to select, or just select what you want and Bring To Front so you can see them. Change them in place then Send To Back again.

You could even group the top layer and then lock it and then send it to the back - totally out of your way. It would keep small things from getting lost, I think. Just some thoughts! Discovering the power of Lock has really made working much easier for me.

Oh!!! And this one!!! Ever want to Arrange > Center to Center on the left object exactly? Lock it first! Then grab the two objects and align them. They arrange around the locked one. It totally tickles me!

Oh, one more thing about Bob's merge idea. If you used Merge, you wouldn't need the calc fields at all.

LaRetta

[ESpringer]

Lots of great ideas... I haven't really used the lock -- at least, I got out of the habit, forgot how useful it could be... mmmmm.

But with a string of merged values, to achieve the effect of letting some values show as one color, and other values show as a different color, doesn't one still need to use multiple calculated fields, each taking the value only if it meets one set of conditions?

Say, not to be a nag... I remember that you said you might post a project soon... have been looking forward to it... did I miss it?

-ESpringer

[LaRetta]

Ooops! You're right on the calc of course! Thanks for catching that!

Oh. The project. I got a bit side-tracked and way-laid on another project for them, but this one should be forthcoming some time this week.

LaRetta

[cjaeger]

combine those techniques above with scripted copy & paste of text and you can script text formatting even on a word/character level. Bob Cusick from www.clickware.com has a nice sample on this.

[ESpringer]

In response to LaRetta's curiosity about work done on GUIs:

Most of my work is so perpetually under construction, since I live in it , and I'm ashamed of most of my working GUIs. But here's one relatively clean and quick attempt to make background graphics highlight what matters on a layout *for this record*. For my biblio/reference database, I want to have a unified browsing layout, despite the fact that different kinds of work (chapters in books, articles in journals, anthologies, etc.) require different sets of fields. It uses container calculations and related container fields to underlay a graphic below the white field name ONLY when the reference type is of a certain kind. In some cases, different color-tags are "stacked" transparently, so that the same field gets highlighted differently.

The effect is subtle VARIATIONS on a layout within the same actual layout. Here are three screenshots of upper-left section of the layout (the rest is portals and long fields), where different color tag underlays allow the field names to show as appropriate. The idle fields are all still there, but user knows they're not relevant to this record. So, the three screenshots below would appear in succession while browsing found records on Dewey...

(Because the tag underlay is identical for all fields, I figure graphic resources are conserved. I'd be curious whether it's better to do one big related-field underlay, as opposed to replicating the same related field in many spots, though it would making tweaking more time-consuming. I also decided not to have colored underlays below any actual fields* because I prefer to preserve tabbing-input and want not to have things look suddenly washed-out when background shows during input.)

Shadow effects come from OmniGraffle...

Note: the last one solves the problem: "How do you use Find mode if all the field tag text is white?"

Answer: Layout background is white. *On top of that, a dark color stretched and locked in place.

The "FIND MODE:" text is also deep down near bottom. You never see these in browse mode because:

On top of these, a graphic field for which *every record* auto-enters (by lookup) one white pixel,

spans data entry area, without data entry allowed. (Global graphic would show in find mode.)

This also avoids the "*******, I just typed a whole record's worth of data in Find mode! @#$%&*^%@#$!"

So, what things do y'all have cooking?

-ESpringer