An Interesting Approach To ToolTips

[SteveB]

This approach appears in the latest issue of Filemaker Advisor, and was contributed by Scott Love of Soliant Computing:

Up until now, I created a calculation for each tooltip in the file that needed the tip. Some of the tips were dynamic abd changed based on what record ther user was on.

Scott's method involves creating a Custom Function to handle all Tooltips in the current file. Pass the CF 2 parameters:

ToolTips( Type; Value )

Case(

Type= "Print"; "Print Information For This Transaction";

Type= "MainMenu"; "Return To The Main Menu";

Type= "Email"; "Send an Email to: " & Value;

)

To use this CF, enter the CF in the tooltip entry window, along with the 1st parameter, and optionally the 2nd paramter:

ToolTips( "Email"; Contacts:Email_Address )

It gathers all the tips into 1 place for ease of maintenance and removes them from the field definitions list. A great use for a Custom Function!

Steve

[JerryD]

Thanks for brining it here. Also, I have in preferences global field to control whether I want to show tool tips.

If(IsEmpty(g_ToolTip);"";ToolTips( "Email"; Contacts:Email_Address ))

Edited February 26, 2006 by Guest

[coconutt2000]

I'm currently using a custom function and global variable to enable and disable tooltips.

function:

DisplayToolTip(tooltip)

If($$showtip="no"; ""; tooltip)

When I get to the part where I need finer control over the tooltips, I'll probably go with a single custom function to define the tooltips. But as my current little itty bitty function does it, it works with any calculations I may use to generate a tooltip, or suppresses it if I decide to. Most of my tool tips right now are informational for my benefit anyhow. I like to see through relationships using tooltips to grab information through relationships so I don't have to add diagnostic fields to my layouts.

Which reminds me, if you have any seriously dysfunctional relationships that just don't seem to work right, it may be that your table occurrences may have been corrupted. This happened to me. I spent 48 hours wasted on trouble shooting relationships that went haywire. I didn't think it was related to a FM crash, because the behavior showed up a day after a crash, and not immediately. In fact, the behavior showed up only as I started work on a set of table occurrences that were corrupted and which weren't losing their "relationships" even after being disconnected. The solution was to duplicate the TOs and reestablish new relationships. So far, so good. Symptoms included an apparently disconnected TO reporting that it cannot be connected to a TO or TO set through more than one relationship instance. Another symptom was in the relationships pull down menus. Relationships I deleted from my graph still appeared in the menu. An indicator that you have a problem is that when you use the visual alignment buttons in the relationship graph, and then save your work when you exit the database definitions screen. If FM hangs and then quits, it has a problem that appears to be related to corrupted TOs.

Just speculation though. I had to backtrack through several days of backups to find an uncorrupted file and rebuild my changes. So far everything seems to be working, and I'm hoping that updating to 8v3 will prevent this from reoccurring.

[xochi]

See this thread for two ways to move the ToolTip text out of the custom function and into a table. One uses a recursive function with GetNthRecord(), and the other uses ValueLists()...

http://fmforums.com/forum/showtopic.php?fid/35/tid/177938/

[Genx]

... What if you have 4000 (or even a more reasonable number like 200) tool tips and it's the last one in that list... every single one of these needs to be checked before getting to that last test, if your tests get more complicated, it takes even longer. When a user hover's over a field, they'll only do so for about a second or maybe two if they actually expect a tool tip to come up.

[xochi]

That's a good question. These solutions work fine with a few dozen tooltips. I've not tried them with a few thousand...

[mf]

I will be integrating your idea of turning off the tooltips:

It should be simple as all my tooltips are in a custom function that requires 3 fields: message number (arbritary unique number), field 1 and field 2. The use of the 2 fields varies for each message (sometimes the fields are used in a test, sometimes they are integrated in the message). I also use a global field for the interface language. I do not store messages in a table, everything is in the custom function.

I use a Case statement and test the message number: it seems pretty responsive. The logic for the message varies. I can now initially test weather to display the message right before the Case statement...

Thanks for the idea! (I am thinking to make this option user specific...)

[Genx]

I utilize 1 custom function and individual tool tips for each field. The Custom Function thats tacked on to each particular tooltip is just:

If(Globals::userSpec_tooltips = 1; tooltip )

I use the above because i'm thinking of making the option "section specific" -- this simply allows me to change the condition for the tip showing easily.

Anyway, my login script retrieves a lot of user specific settings from my accounts table... one of which is whether they want the tooltips shown or not. Globals are easy and even appropriate in this case :/.

The chance of my tooltips changing dramatically are fairly low though using a CF for extremely repetitive tooltips (as in the example steve posted) seems like a good idea.

[eos]

btw...

if you use a global number field for flags like tooltip and set it to either 1 or empty, you can shorten a calculation like this one to a brief

case ( myTable::toolTipFlag ; )

because the number field can be utilized as a boolean value; so a 1 in this field resolves to "true" and triggers the tooltip

cheers

eos

PS: and I humbly advise to the usage of "case" instead of "if", because (besides other advantages) it doesn't need a "test=false" value (as is evident from the example above)

Edited September 7, 2006 by Guest