Iconic representation

[K1200]

I'm revisiting a topic I pondered over a year ago: How to display iconic representations of information without having to store the corresponding icons in the individual records?

Up to now, I've used a container field or two in a very limited number of tables, with each field using a lookup-style calculation. This has always seemed cumbersome for these reasons:

In records with just a handful of text and numeric fields, adding corresponding container fields for icons greatly expands the table size*.

Displaying corresponding icons should be a runtime activity -- equivalent to the Format as Boolean capability for numeric values.

Deciding (at runtime) to display different icons for a field requires updates to all respective fields/records.

Compounding these issues is the fact that today's users have come to expect more graphic representations -- so standing still means falling behind. So my question is:

Is anyone aware of a technique to link to what I would term "external icons" that are referenced by specific layouts at runtime? (and that could be used in portals, of course) In other words, icons that are looked up at runtime according to the current value of related fields -- but that don't reside in the records.

*in certain instances, using text fields with Webdings can get around this at the cost of limiting the graphics.

[comment]

Use a relationship to display the icons directly from their own table?

[Fitch]

I like to keep a one-record table that stores my graphics, e.g. "next arrow," "previous arrow," "home" or whatever.

I use a startup script to load these graphics into corresponding global fields, either in the same table or a separate globals table. The beauty of this is that globals can be referenced from anywhere, no relationship required.

You can then reference these globals via unstored calcs. Yes, this means cluttering your schema a bit. However, since the calcs are unstored, it doesn't appreciably affect your file size to add these fields to as many tables as needed; they are only ever stored in one place.

[K1200]

Use a relationship to display the icons directly from their own table

The beauty of this is that globals can be referenced from anywhere, no relationship required.

I'm trying to get my mind wrapped around the possibilities here, so please bear with me on this. If I want to work strictly at the layout level (and not modify the data source table), it seems the following would work for normal layouts:

1. For each set of icons, define a dimensioned field in a global related table to hold the X number of icons required.

2. Then have a calculated field in that same global table that references the correct icon according to the current value of the data field (i.e., = Icon[ DataTable:: DataField])

3. Then simply display CalculatedIcon on the layout

But will the displayed field from the icon table refresh correctly when used in a portal? I'll be able to test this tomorrow.

[Ocean West]

try this out...

http://www.filemakermagazine.com/videos/using-global-graphic-variables.html

[Fitch]

Step 2 sounds backwards and won't work if I'm understanding what you're proposing.

What I'm talking about is:

1. setting up a separate global field for each icon. It's much easier to work with named icons than numbered repetitions, and since this table is dedicated to icons there's no reason not to do it this way.

2. in any other table, set up calculated containers to reference the global icons.

For example in the Contacts table:

Left Arrow =

Case( Get(RecordNumber) = 1;

      Globals::Left Arrow Dim;

      Globals::Left Arrow Lit )

Right Arrow = 

Case( Get(RecordNumber) = Get(FoundCount);

      Globals::Right Arrow Dim;

      Globals::Right Arrow Lit )

These fields can be copied and pasted into all your tables and they will work. 



Those aren't really good examples of what you might use in a portal-- you haven't said exactly what your application is-- but you might use something like: 

Case( Qty>100; Globals::Alert Icon )

This would be defined in the table that is referenced by the portal.

[K1200]

If I want to work strictly at the layout level (and not modify the data source table),

To clarify a bit, I'm currently working with a data file in the separation model so that modifications to the foundation file can't be done until the next major update. However, by working with a table that's local to the interface file, I hope to build some "virtual" technology that will fill some of the immediate requests.

My initial testing has shown that using an unstored calculated container (in my Step 2) does produce a usable result -- but I haven't tested it with portals.

The idea of using global variables to hold the icons is an interesting one.

Thanks for all the suggestions.

[K1200]

My result: the external icon table approach almost worked for portals.

The captured screen clips below show the method I tried. The Icons::Current field does display on each row of the portal, but the contents are always relative to the first Entries record in the portal. In other words it doesn't update per each row's entry. That is apparently due to the lack of a choice for evaluating from the context of "Entries".

Further suggestions will be appreciated, of course, but it looks like I'll have to shelve current user requests for lack of a method.

Thanks again for the responses.