Not exactly (since this is a related field and therefore not local data). However, you could run an OnTimer script that checks the status field on some frequency.
Hello Rafael and Mike,
There is a possible technique for this sort of thing that I've not seen discussed much. I don't know if there's a good reason for that that I've missed or not.
I'm hoping that by mentioning it here we might be able to evaluate it as a potential solution for Rafael's system, as well as for other scenarios where this comes up from time to time, e.g. sending a message from one FM client/user to another.
The gist of it:
1) Make use of a calculation that FMP will be constantly monitoring for changes
This will take the place of our using an OnTimer script to constantly watch for a status change.
A nice example of a constantly monitored calculation is the Hide Object When calculation in v.13.
Even changes to non-local data referenced via relationship within the hide calculation trigger a re-evaluation by the FM calc engine.
This gives us our hook to "wake up", evaluate our condition, and conditionally trigger a script.
2) Make use of either a plugin or a WebViewer to trigger a script via the FM calculation engine.
In non-FmGo scenarios, I would tend towards a plugin (e.g. BaseElements, ScriptMaster), because I feel that it would more robustly survive OS updates than a WebViewer
In an FmGo scenario, the WebViewer becomes the only means that I currently see to trigger our script
3) In the calculation that FMP monitors, include a check for the condition change that concerns our system, and, when we see that the condtion has changed, we trigger the script using the plugin/webviewer.
This can be accompished with a calc that incorporates some condition checking, and which conditionally evaluates a statement that triggers the plugin/webviewer.
* I'll attach an archive of sample files to illustrate this idea. *
The advantage that I see to this technique is that it can eliminate the need for an OnTimer script.
The big disadvantage that I see to this technique is that it requires a modification to each layout that one might have open when monitoring for a trigger.
I have tried to see if I could work around the multiple layout modification drawback by triggering off of a calc embedded into a custom menuset, e.g. "Enable Menu When", but my initial attempts at this have not been successful.
It may be that the custom menu calcs are not constantly monitored by FM, but are only revaluated on a Window change. This would make sense to me.
In Rafael's case, we are checking for a change to a specific related record, though in other scenarios, we might simply be triggering off of a single record table which maintains a single status value.
Though the implementation details of these would differ, the same underlying technique of triggering from a constantly monitored calculation could apply.
I would not argue that this techniqe is better than or worse than an OnTimer approach, but rather I see it as a possible alternative that we might consider as something that we might keep in our toolbox.
Kind & best regards,
Message was edited by: steve_ssh Made one small change to the WV example in archive. Uploaded new attachment: 20140902
TriggerExample_20140902.zip 202.6 K
I've tried the OnTimer script and it solves my problem.
I found your approach very interesting, since it opens alternative ways to solve the problem. I would probably stay with the OnTimer script step solution, but you show a very creative way to leverage the use of the constant monitoring calculations, which I had not realize their existence... Thanks for you detailed sample files which I will keep them in my toolbox from now on.
Steve is a never-ending source of wonderfully clever solutions.
@Mike and Rafael: Thank you both for the positive words which brightened my day.
Rafael: Glad you got a good solution working!
Very best to you both,