Thanks for the comments everybody, which prompted some further
thinking and fiddling.....
I will just summarise the final outcome here – maybe
someone else will have a use for this. Script triggers can be tricky, but can
be made to work (with some time & effort)......
Ended up with :
+ the portal rows auto sort (as per relationship definition), based
on a user-entered port sequence field (number), so user starts with
1, enters first port name, then next row is 2 and so on. New ports can be added
or inserted at any time, eg 1.5 to add a new port between ports 1 and 2. A
script trigger snaps the focus to the new (now sorted) portal row and the port
name field.
+ then used on-object entry trigger on 3 of the day fields, and
on-object exit trigger on the final day field – this trigger script stores
the originating row and field name (using script parameters), loops through the
portal rows, setting the arrival date from the previous record (stored as a variable
before leaving each portal row).
+ on final portal row, exits the loop, sets a variable to bypass
the current script from being triggered again, and goes back to the originating
portal row and field. The on-object entry trigger is bypassed (halted) by
looking at the variable set in the previous run of the same script. Otherwise of
course it enters a continuous loop.
+ deleting a portal row by button also launches a similar recalculation,
but does not return to the portal.
Doubt that the users will appreciate the time put into this, but
it’s really neat to see the dates recalculating instantaneously as you
move through the fields. I suppose if there were a large number of rows, this
would be a bit clunky.
Regards
Peter
From: FileMaker Pro Discussions
[mailto:[log in to unmask]] On Behalf Of John Weinshel
Sent: 03 March 2014 00:40
To: [log in to unmask]
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 <[log in to unmask]>
Reply-To: FileMaker Pro Discussions <[log in to unmask]>
Date: Sun, 2 Mar 2014 23:01:21 +0200
To: <[log in to unmask]>
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:[log in to unmask]]
On Behalf Of John Weinshel
Sent: 02 March 2014 21:32
To: [log in to unmask]
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:
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 <[log in to unmask]>
Reply-To: FileMaker Pro Discussions <[log in to unmask]>
Date: Sun, 2 Mar 2014 15:12:30 +0200
To: <[log in to unmask]>
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:[log in to unmask]]
On Behalf Of John Weinshel
Sent: 02 March 2014 04:40
To: [log in to unmask]
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 <[log in to unmask]>
Reply-To: FileMaker Pro Discussions <[log in to unmask]>
Date: Sat, 1 Mar 2014 17:35:56 +0200
To: <[log in to unmask]>
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