First. The tooltips are triggered by hovering over an object and not by clicking on the objects.
Second. You can weave various data or calculations into the tooltips but bear in mind, that any data has to be available either directly or by relation to the record you are currently viewing. Data can either be from fields or global variabels. Local variables will not work.
Where are you storing that last modified timestamp?
Perhaps I said something incorrect, the tooltips are indeed when hovering over objects, the data in them is at the moment triggered by clicking in the layout. That is the problem I am having, it should not require a click to register the data, yet it is requiring such.
The timestamp comes from a table, the same as the one with the field being hovered over. Both are inside a portal, all data of which is stored in a separate database in a data separation model.
Getting data to display in a tooltip from over an object within a portal should work fine, even if the table is an external table as long as it has an occurrence in your main database.
Make sure that you're using the correct relationship occurrence when referencing the field in the tooltip.
I use these all the time both in local and external tables and this works flawlessly. But when this belongs to a field in a portal you have to make sure that you reference that very relationship.
So lets say your Tooltip is defined as follows:
"Modified: " & ChildTable::modifiedTimestamp
When you arrive on the record, and you hover over the object in the portal, you see the word "Modified:" and the last modified timestamp.
Are you telling us that once you've started to edit the related record, that the tooltip will not come up at all until you've clicked in the background of the record? Or are you saying that you only see the hard-coded "Modified: " text with no actual timestamp shown? Or is there some other aspect to this that I'm missing?
You may need to combine a refresh window with the commit records if there are enough "layers" between the data and the object with the tooltip such that commit records doesn't properly correct for the problem.
But since clicking the layout does exactly that, it commits records, it's surprising that your commit records script step isn't correcting for this here. I'd definitely double check that the script is being performed when you think it is and that it commits the data before you can hover over the object and get the tool tip to appear.
I would not use the Flush Cached Join Results unless absolutely necessary. It can produce a very undesirable performance delay in getting a layout to update.
But DO use the other option (Flush cached external data)?
This is a separation model design, we are told.
The problem here is not so much that the relationship is an issue, it is more a problem that it doesn't wish to display any of the data until after I have clicked on the layout. After that it works perfectly fine until I switch layouts.
I have eight layouts, all with different relationships, where this is an issue. Either I am heavily inaccurate with selecting relationships or there is something else going on here. Looking at the relationships, I can find no anomalies. The tooltips are referring to the proper relationship, in fact in one instance the only table occurrence of said table.
Your example is correct - "Modified: " & ChildTable::modifiedTimestamp
But you are incorrect in the step of operations. I am saying that just navigating to a different layout, then hovering over that object in the portal, only results in "Modified:" appearing with the problem being the lack of ChildTable::modifiedTimestamp.
To get ChildTable::modifiedTimestamp to appear, the user needs to interact with the layout. Clicking somewhere, editing something, anything appears to work fine. It just has problems if the user does not interact with it.
I have added a Commit Record step to the script loading on record switch, plus a Refresh Window (both options checked). Perhaps it is my imagination but it seems to make the layouts load faster. Regardless, it does not seem to fix my issue. I added the other two, nothing changes. All are being run according to the Script Debugger, but none seem to solve the problem. Also, before it is assumed the script messes something up, I should note the first line is to switch layouts, which by itself still results in the issue occurring.
See my reply to BruceRobertson, the inclusion or removal of the flush options does not solve the issue. I do find it weird indeed that a simple click is able to solve something that seems this complicated by scripting. I am not sure if it helps, but the file in question is hosted on a server.
Using the script debugger, I can confirm that there is no script running when the user clicks on an empty space in the layout, causing the tooltip's data to work properly. I can also confirm the commit and window refreshes are indeed performed.
1 of 1 people found this helpful
Do you have the latest updates for your version of FileMaker?
Did you try running Recovery to see if the file has any problems?
I don't know what's going on but just to isolate further... can you isolate which actions cause the tooltip to start working? entering a field? typing in a field? exiting a field? Just because it made more sense before when it sounded like you had to click in the background of the record (which forces a commit). Even that doesn't make sense though... the data should be showing in the Tooltip when the record loads.
My version is 18.104.22.1685, so it is up to date.
I ran Recovery on both files, neither detected any problems.
To isolate further, I have tested it on Local with the same results as on Server. Entering a field, without typing or exiting it, fixes the problem. When I said user interaction, I meant pretty much anything involving a click or navigating between fields. I could press tab and have it work. I can also click somewhere random on the record and have it work. Buttons are the same. It heavily sounds like a forced commit, yet a forced commit (script step) doesn't fix the problem.
Do you have more than one window open? Could it be that the click is activating the window?
That could potentially be the case. I don't have more than one window open when doing this, but at the same time the data separation model means that it is simply a hidden window. I would not rule it out. I have tried including a Select Window step, but nothing seems to change.
I was thinking more in terms of two windows open side by side. While DS means that you have a window open and hidden in the background to the data file, it isn't normally an "active" window. And just opening a window in FileMaker makes that most recently opened window active unless something else is selecting a different window--such as opening a window hidden "off the edge of the monitor" that now is the active but not visible window...
When I open our system to a UI file that uses data separation, I simply open the window and hover over a an object with a tool tip and it appears. It is set to display data from a field from the data file, but I'm opening FMP 13 on windows so there could be differences there that explain this. I also set up a tool tip on this layout to show data from a related record and it also pops up with data as expected.