Interesting post. Thanks for highlighting this issue. i guess we just have to code our trigger scripts to handle this kind of situation. There are several ways of dealing with your particular situation, but probably no absolutly 'right' solution. The many possible options include:
- Avoid this by changing to an appropriate layout with the onLastWindowClosescript
- Have the OnRecordLoad script check it is on the right layout (or in the right context)
- Have the onFirstWindowOpen script include a Halt at the end (a very blunt instrument)
- all the other solutions
I guess the best solution depends on your situation.
Thanks again for bringing this up.
As you say, there are plenty of solutions for this particular case.
I'm posting this as a warning/question. Vaughan has been warning people about the dangers of script triggers for a while and I'm doing the same.
This shows that we cannot make any presumptions about the context in which the triggered scripts will be performed. All we know is that they'll be put into the queue and fired in order.
Initially I had trouble identifying the error because the script trigger was on a different layout. There was no connection with the place in which the error was occurring. It wasn't until I opened the file with debugger running that I could see why it was happening. This problem is occurring because the OnRecordLoad script is triggered by the initial context of the database. However, at startup the onFirstWindowLoad script has precedence and runs first.
Most of the time it simply isn't necessary to think too hard about context because Filemaker looks after that. In this case an OnRecordLoad script is attached to a layout. That layout is tied to a table occurrence which in turn has a base table that contains the data. It is reasonable to expect that the script will be performed on that layout and not another. Wrapped up in that expectation is that the script will be performed on a record from the Table Occurrence/Base Table linked to the layout. A pseudo-code approach may be to say, "when a record from this table occurrence is loaded perform script XYZ with parameters drawn from the current record".
My question is "Should layout and record level triggers be observed if a preceding trigger changes the context?" Shouldn't they be dropped?
In this case it is shown that OnWindowOpen, OnLayoutEnter, OnModeEnter, OnRecordLoad can all be triggered prior to OnFirstWindow but onFirstWindowOpen is given priority and performs first. My feeling is that OnFirstWindowOpen should start with a clean slate. If it is going to perform first it should behave as if it really was first in the queue. At present it doesn't do that. If it were first, those other script triggers would not have gone off.
Digital Fusion (now teamdf.com) has a great article on suppressing triggers. I highly recommend reading it.
agnes b. riley . filemaker and web development
T 201-299-6223 (NJ) . 212-842-8830 (NY) . 917-660-7221 (C)
FileMaker Certified in 10 and 11
Here's the link, for those who missed it.
Weetbicks articles are very interesting. Once you check out the above, look at more of them!
I ran into the same problem with a DB I'm working on. My solution was to set the "when opening this file switch to layout option" and set up a script for "Onfirstwindowopen" script trigger. This seemed to resolve the problem for me.
In my case, the user saw the last layout used before seeing the correct layout. This seemed to resolve the issue.
As far as your question about context and Onrecordload or Onlayoutload script triggers goes.. If the layout or record is opened, the trigger should run. I don't think FM can tell that it is in transition to another layout and determine that the script should be skipped " this time".
Cool. Thanks for sharing.
I recommend that article too. Scripts that will be triggered should be very careful about when they are run and by whom.
As background, the example I posted is an extract from a client file. I made it delete files to make the point obvious, the core of the problem is the product of a bright, naive user. I know that they are interested in doing "clever" things like automated clean up of incomplete records and it's just luck that they didn't try to implement it.
Filemaker is all about context and in this case the context is being ignored.