Often, I end up not using an on mod trigger, where I thought I would. Aside from responsiveness issues (of course the user's disk will stall at the worst time), I have annoyed myself with these, as I am used to being able to type in an open field without any functions running.
It seems like an on exit would give everything wanted here. This assumes the tab order is set properly. Set variable $prow; Get(ActivePortalRow) Set variable $pfield; Get(ActiveFieldName) Commit Records Do Script (Recalculate) Go to Portal Row ( $prow ) Go to Field ( $ pfield ) Go to Next Field But of course, that's no good, and is why I'm posting: Every time that GotoNextField is executed, the exit trigger runs the script again. I thought there was a way to disable script triggers for reasons just like this, and this thread has made me look, and I'm not finding it. I was faced with this recently, and I ended up passing the next field name as a parameter. It wasn't that many fields, and I had to hurry up and move on to something else. So without a way to disable triggers in the system, a flag would have to be used: If($$StopFlag = "True"; Set variable ($$StopFlag; "False") Halt Script; Else Set variable $prow; Get(ActivePortalRow) Set variable $pfield; Get(ActiveFieldName) Commit Records Do Script (Recalculate) Set variable ($$StopFlag; "True") Go to Portal Row ( $prow ) Go to Field ( $ pfield ) Go to Next Field End If But that's no good either. I've stopped the exit cascade, but I don't think I've actually entered the next field; the script halted upon exiting the current field. I can't think of a way around, besides passing parameters and targeting the next field directly. Geoff From: FileMaker Pro Discussions [mailto:[email protected]] On Behalf Of John Weinshel Sent: Sunday, March 02, 2014 5:40 PM To: [email protected] Subject: Re: Exit portal trigger Sounds like your basic structure is working and you would just like to refine the interface. While you are correct that the on-mod trigger requires a value list unless values can only be single character, what's wrong with using a value list? Is there a possibility of needing an unexpected value? As for an 'on-exit field on each of the relevant fields', getting back to the right place isn't so hard and might be a useful learning exercise. You'll want to capture the portal row and go back to it (or the next one, depending on your logic), and probably also the field name and branch your logic accordingly. In other words, if there is more than one portal row field with the same trigger, the choice of which field to go to next would be based on which field is being triggered. Use Get(ActivePortalRowNumber) Get(ActiveFieldName) to determine your starting place. To return, use GoToPoralRow[] and GoToField[]. Good luck, John From: Peter Buchanan <[email protected]<mailto:[email protected]>> Reply-To: FileMaker Pro Discussions <[email protected]<mailto:[email protected]>> Date: Sun, 2 Mar 2014 23:01:21 +0200 To: <[email protected]<mailto:[email protected]>> Subject: Re: Exit portal trigger Hi John The solution I have is a close match to what you describe. I did simplify my description of the portal records (there are fields for days inport, days at sea, days at anchorage etc), but everything works and the script quickly recalcs all the dates and sorts the ports into the correct order. So it's looking really neat. When users leave the layout the script is run again, making sure voyage start and end date are correct ( as these dates are used elsewhere in the system). When rows are deleted, the delete button also runs the recalculation script. All I was wondering is - can I avoid a dedicated button on the layout to run the recalculation script? I thought I could trigger the script on each portal row exit, or on exiting the portal, but this does not seem possible. I avoid the on-mod trigger because it requires a value list. I could use the on object exit trigger on each of the relevant fields, but would then have to be able to return to the portal row and to the next field - that looked a bit complicated. I think the answer is a button on the layout, users will just have to live with that. Thanks Peter From: FileMaker Pro Discussions [mailto:[email protected]] On Behalf Of John Weinshel Sent: 02 March 2014 21:32 To: [email protected]<mailto:[email protected]> Subject: Re: Exit portal trigger I'm not clear just what the problem is, but that may be because I am not following how you want to enter the ports. Here's what I think you are describing. Please correct me where I'm wrong: 1. Users will be fiddling with the itinerary, so you need to update the departure and arrival dates whenever any of the length of stays are changed. 2. If that is the case, that update would be managed by a script that, in pseudo code, looks like this: * Set Variable $ArrivalDate to the date of the arrival in the first port. This could be a date field or global date field in the parent record. * GTRR to child records (best done in a separate window). * Sort the found set of child records by day number. You can't use the date, because it's being changed and is thus not dependable. If these might be switched around, you'll need a way to change these day numbers. They should not be primary keys. * Go to the first record. * Loop * Set Field[Arrival_Date; $ArrivalDate] * Set Variable $ArrivalDate to Departure_Date (the calculation of Arrival_Date + number_of_days) * Go to Next Field [exit after last] * Close Window (Current Window) if the GTRR in step 2 opened a second window I can't otherwise see how 'arrival date is the departure date from the previous record in the portal' would work easily and be dependable. Extracting that previous record's departure date is doable but requires a bit of extra programming. A loop for a handful of records should run almost instantly. You could trigger it to run whenever a length-of-stay is changed, but that seems tedious and a simple 'Update' button next to the portal ought to suffice. If you do decide to use an on-mod trigger when the length-of-stay is changed, make sure that field's value uses a pulldown list of numbers; otherwise, the script will run after the '1' is entered for a 10 day stay. Not necessary if stays are dependably always shorter than 10 days. I am assuming you are entering child records into a portal, on a Voyages layout, where 'Allow creation of related records' is enabled for the portal's TO. But, as I say, that may be a false assumption. John Weinshel From: Peter Buchanan <[email protected]<mailto:[email protected]>> Reply-To: FileMaker Pro Discussions <[email protected]<mailto:[email protected]>> Date: Sun, 2 Mar 2014 15:12:30 +0200 To: <[email protected]<mailto:[email protected]>> Subject: Re: Exit portal trigger Hi John I have two tables, Voyage (parent) and Ports (related records). For each voyage, user creates portal records, entering a port name and number of days in each port. A departure date (calculation field) = number of days plus arrival date. Arrival date is the departure date from the previous record in the portal. Except in first record, where user enters a date. I run a loop script to set the arrival date into each record. GTRR, go to first record, set departure date to a variable, go to next record, apply variable to arrival date field etc. I am trying to trigger the loop script when the user exits the portal, instead of having to click a button on the layout to recalc the dates. Regards Peter From: FileMaker Pro Discussions [mailto:[email protected]] On Behalf Of John Weinshel Sent: 02 March 2014 04:40 To: [email protected]<mailto:[email protected]> Subject: Re: Exit portal trigger So far as I know, the portal object itself cannot be entered or exited. While you can name the portal and try to capture its focus state using GetLayoutObjectAttribute(portal_name; "hasFocus" or "Source" or "ContainedObjects"), an OnObjectExit script setting this value will not fire when you move into or out of the portal. Running that script on entry from every other enterable object on the layout would be a terribly kludgy workaround. I'd be happily surprised to hear that a portal is exit- and enter-able. What are you trying to accomplish? There may be another way to get there. John Weinshel From: Peter Buchanan <[email protected]<mailto:[email protected]>> Reply-To: FileMaker Pro Discussions <[email protected]<mailto:[email protected]>> Date: Sat, 1 Mar 2014 17:35:56 +0200 To: <[email protected]<mailto:[email protected]>> Subject: Exit portal trigger Hi Windows and FM 12 Pro. Is there a script trigger that will run when a user clicks (with mouse) anywhere outside the portal? I tried OnObjectExit, but this runs each time user moves to the next portal row, whereas I only want the script to run when he exits the portal. Thanks Peter
