1 of 1 people found this helpful
Here is an idea to play with.
Hide Object When + Calculation Nudging:
If you are using FM13, you might try seeing what you can get out of using conditional object hiding in conjunction with a single row table that all clients are allowed to "nudge" by updating a value in the single row.
The idea would be that when a client sends a message, the message-sending script updates a field value in the single row table.
A "hide object when" calculation which references this nudged field would then know that it should re-evaluate.
The re-evaluation could test for conditions which determine whether or not the given client has received a new message.
If it is determined that there is a new message, the "hide object when" calc returns False, thus revealing a layout object which alerts the user to the new message.
Otherwise, the "hide object when" calc returns True, thus maintaining the concealed status of the alert layout object.
The above has some obvious drawbacks:
1) Extra schema is required (the single row table, plus a relationship to this table from *every* context that the user may be working in)
2) The "alert" layout object has to be added to every layout that the user may be working on.
3) If the user has multiple windows open, it probably would look funny to have the alert appear on multiple open windows.
Within the context of a Pro/Advanced client, one could probably use a variation on this idea whereby a plugin (e.g. ScriptMaster, BaseElements) is used to trigger a script via calculation. The script could then trigger a FileMaker dialog (or open a new window with a customized alert layout).
This should mitigate drawbacks 2 and 3 mentioned above.
My main reservation with this idea is the extra schema that would be required if the users do their work in several layouts based on different contexts.
Beyond that, I think that the other main caveat would be that this sort of design would require a lot of testing and thoughtfulness to make sure that it would really perform as desired without generating undue amounts of extra client-server traffic.
I'll attach a file that I started, just to see if the idea could work at all.
I recently implemented a solution into a fileMaker Go db. It will display a message indicator at the top of the screen (similar to message badges on the iPhone) that relays how many unread messages there are for the user. You could just as easily have something that displays text from the latest unread message from your message table. The count automatically increases based on the way I have setup the relationship graph, and calculated fields (total # of messages - read # of messages). You could use an onTimer event to check for any unread message count and displays the message in a dialog box, or even a popup window.
Thanks for sharing your thoughts. Much appreciated. That's certainly helped.
I'm wondering, rather than a single row table - because there could be conflicts. ie a second message to someone else before the first one is cleared - set up a table where each user has their own record (based on their unique user name/id). I've done this in a few instances over the year like when someone clicks on a thumbnail and it opens a bigger version in another table. Then clears the field when they leave. There's always 1 (and only needs to be one) field per user.
I could then run a timer script on everyone's client machine say every 5 mins triggered from when they logged on. If not empty
This would then open a new window - which would not be dependent on which layout they were on - showing their record and say 'you have a new message - sent by Fred on 19/4 10:22' with a button to clear field and close window.
thanks for your thoughts which, with those of Steve got me thinking better. See my comments attached to his and more below.
I think with a mixture of is field empty; a new window/pop up (can you script a pop up to open?); and a new table it could work.
 From a list generated by user_names a message could be left for a named user on a separate table.
 When that user logs on an on timer script runs to find if there are any messages on that table
 if yes opens a new window showing those related new records
 on 'close' clear all messages
Running an on timer script in the background and a new window means that it's never dependant on the dozens of layout the user might be on
I like it!
What do you think?
It looks as though you have hit upon a plan which may work well for you.
What I particularly like about your proposal is the liberation from a lot of repeated layout content (and schema) that would have been required by the idea that I proposed.
Regarding OnTimer Script Steps:
When possible, I try to avoid running continuous onTimer scripts at a short interval, hence in my post I was suggesting something that would not require such a technique.
At a five-minute interval, I do not feel that you are asking too much from the system.
Had you said that you wanted to run the script at a much smaller interval (e.g. every 5 seconds), I would probably try to encourage you to rethink your solution.
However, with your proposal of a five minute interval, I really don't have the same reservation, and I look forward to hearing how it works out for you.
So, perhaps you will post back when you have something working well and let us know how it goes?
Very best wishes,
Regarding the One Row Table Approach:
There is a way to use a single-row table which would not be subject to the multi-user conflicts that you might anticipate. The key to this is that the single row only serves to broadcast the fact that a new message has been posted to *someone*. The single row does not store any data about the intended recipient of the message. Its only function is to prompt all clients to check to see if they have a new message, and it does so anytime a new message is posted for anyone. In this scenario, clients are not continuously checking for messages on a timed interval -- they do no checking at all until they receive the prompt from the single row being modified. It is a different approach from the direction that you are heading, though one which I would say is arguably neither more nor less preferable -- just different.
We had an on timer, for a similar notification scheme, and the users found it annoying. Try it
> Running an on timer script in the background and a new window
It should work. I do, however agree with Steve_ssh about considering if you might overtax your solution by introducing a continuous on timer script with too short an interval. If the client is set on having something popup on the screen, is it critical that it be instantaneous? Can you get away with x number of minutes rather than x number of seconds to refresh the timer? My situation my not apply to your need, but I am pleased with how our notification icons works. The message count updates instantaneously from the calc engine, no on timer required. Using conditional formatting, the notification is easily seen, but not too obtrusive or annoying (to gdurniak's point). Do you really want/need to have the whole solution come to a standstill in the middle of whatever you are doing to force an immediate response to a message? What if you are in the middle of data entry and you get a message popup. That could get old really fast. How many messages and what frequency are anticipated? I guess if it is a rare occurence then it might not be as much of an issue. But then you have to ask the question if such a rare occurence is worth the on-timer overhead.
Yes, you can script a popover to display. Name an object that is on the popover, and then use a gotoObject script to go to that named object. The popover will display.
Thanks for every one's comments. It really does help. In fact the solution is easier than I'd hoped.
 Someone fills in 2 existing fields on a record they want someone else to look at ie 'recipient' (a drop down list of user names and 'message'.
On a button or on field exit script trigger invoke script 1
 Script 1 sets 2 variables $recipient and $message which is a calc saying…
Get ( CurrentHostTimeStamp ) & "¶A new reminder has been posted for you by " & Get (UserName) & field:Message
 Goes to a new table called 'reminders' and creates a new record
 Sets 2 fields 'recipient' and 'message'
 Goes back to original layout and shows a custom dialogue 'Your message has been posted'.
 A second script (triggered by an on timer script (every 5 mins) set up in the start up script)
 goes to the reminders table and does a find for the Get (UserName) in the recipient's field
 goes into a loop that if Get (FoundCount) = 0 goes back to the original layout and exits the script
 or shows a custom dialogue box which shows the field 'message' ie Get ( CurrentHostTimeStamp ) & "¶A new reminder has been posted for you by " & Get (UserName) & field:Message
 on clicking ok it deletes that record (in the reminders table and loops back. So shows other messages waiting for that user.
 goes back to original layout
The original 'recipient' and 'message' are still on the original record which they find/sort the usual way.
What I love about it is that a small dialogue box appears on whatever screen they are working in and is dismissed with by hitting return. I never thought it could be that simple. Nice when it is, isn't it?
Just a couple of thoughts for you to consider regarding your plan which might allow you to simplify further:
1) In Script #2, item #7, assuming you are on v.12 or v.13 fo FM, you might consider using the ExecuteSql function to check for the existence of your reminder record. The benefit of this is that it would not require you to navigate the user off of their layout at all to perform the check. This might help make the script feel less disruptive to the user.
2) You might consider adding a status field to your existing message table, which indicates whether or not the message has been "announced" to the recipient. Each record in the message table starts its life with a status that indicates "unannounced". Then, in Script #2, item #7, rather than look for a new record in your new Reminders table, the script simply looks for the existence of any record in the Messages table with the intented recipient, and a status that indicates "unannounced". The script then continues as planned, and shows the alert, and then, rather than deleting a record in the Reminders table, the script updates the message record to have a status of "announced". This modification to your approach would remove the need for a Reminders table, as well as the need for most of the steps in Script #1.