I encountered an issue that I thought important to share.
(Added based on feedback) In short, Set Field can trigger a field script trigger in WebDirect.
The setting
I was troubleshooting an order solution. Users of this solution can opt to pick up their order or have their order shipped. They do so by selecting a value in a deliveryMethod radio button field that has an onObjectSave script trigger. Opting to pick up an order (value pickup) functioned as expected. Opting to have an order shipped (value shipping) functioned as expected in FileMaker Pro but malfunctioned in WebDirect.
The logic
The workflow when opting to have an order shipped is to open a card window that displays a list of shipping addresses. Users can select an existing address, create a new address or cancel the entire operation. Execution of the triggered script ends when the window is displayed.
Because users can cancel the address selection or creation, the triggered script resets deliveryMethod back to pickup prior to displaying the card window. The scripts that select an existing address and complete the creation of an address will both set deliveryMethod to shipping again.
The rub
Resetting deliveryMethod in WebDirect resulted in an infinite loop. It seems that the Set Field script step triggers the onObjectSave script trigger for the field. Interestingly (I am being kind), the new trigger occurs after the former triggered script ends and the latter triggered script sees the deliveryMethod value as the one prior to reset (think about the implications here).
The workaround:
There is one thankfully. Instead of using Set Field, I now set a variable called $eventCanProceed to True when deliveryMethod is pickup and to False otherwise. I then have the trigger script cancel the Command/operation (Exit Script with result $eventCanProceed).
Set Field should not cause a layout object trigger to be evaluated.
Is the Delivery Method field active on the layout? It may indirectly be included in the evaluation sequence if it is active and the record is committed.
I am aware that Set Field should not cause a layout object trigger to fire. That’s why I wrote this post. As noted, this issue doesn’t come up in FileMaker Pro.
Is the Delivery Method field active? It is the field that contains the onObjectSave script trigger so, yes, it is still active during the trigger script’s execution.
Is the record committed? No. This is a radio button field. The record is open for edits when clicking a radio button value and, as a radio button selection doesn’t exit a record and the script doesn’t force a commit, the record remains in an uncommitted state.
I think you may be onto something. That said, this remains an unexpected behaviour for a script trigger. It certainly runs counter to documentation I read about script triggers and set field.
If the record is open when it receives a commit instruction the active field is saved and script triggers are run. That's expected behaviour.
UX for Radio buttons and Checkboxes is not good in WebDirect. It creates problems as typical web behaviours conflict with typical FileMaker behaviours.
Replace radio buttons and single checkboxes with button bars.
Replace multi-option checkbox fields with multi-select portals.
SVG icons for checkbox and radio button attached. Use conditional formatting to show/hide the fill. In the checkbox the fill is the tick. In the radio button the fill is a circle.
I ask because I've run into similar WebDirect bugs with field values not being saved properly. For example, in some cases I found that the last field edited was not saved in WebDirect if you navigated to another layout via a button script. My solution to this bug was to do a "Go to field (blank)" step before the Go To Layout step.
However, I think this may have been fixed in recent FMS versions, see these notes:
Text fields incorrectly displayed cached data from the previous record when navigating between records, showing the wrong content until the field was clicked. [Fixed in 22.0.1]
Entered text disappeared after being typed before record commit. [Fixed in 21.0.1]