OnObjectModify should trigger the script each time you "modify" the field. Thus, typing a single letter in the drop down or selecting a value from the drop down list's values should be triggering your script. I usually use OnObjectExit for dropdown lists so that I can type into the field and not trigger the script with each key stroke.
If that info still doesn't get things working, you might put a show custom dialog at the beginning of your script. Maybe it is being triggered and the script isn't doing what you expect it to.
PS. Filemaker Advanced's Debugger tool is a great method for figuring out why a script trigger isn't working as you can watch what happens step by step.
custom dialog was good suggestion, thanks. That helped me to see that the trigger is in fact being called. The trigger script (now) begins with show custom dialog... and continues like this:
If (ORDER::shipping = "CarryOut") Set Field (ORDER::shipping_Cost; 0) End If
Need to test for one of 3 values for ORDER::shipping-->CarryOut, USPost or UPS so figured the "If" test was a simple, perhaps not most elegant but, way to get there
You may find you want to set your field to look up such costs from a related table. That way you can change costs in the related table as needed and the field will look up the latest matching cost on each new record and no script or trigger is needed.
If that looks useful, check out the looked up value auto-enter field option to see how this can be set up.
It's a good idea to keep shipping costs in a table, to enable updating them there. And I've already built such a table from which app can grab sales tax rate and 4 different shipping charge rates (one being $zero). Am beginning to wonder if sales tax rate needs to be in an entirely separate table (had liked the idea of keeping all "rates" values in one place).
I'm a bit puzzled how to work out grabbing the correct shipping rate from the table though, without under code explicitly having it selected programatically. I'm at this moment also not clear on how to make the shipping rate table a related one. What could be the relationship?
If I write part of a scrip that walks through process of evaluating the condition criteria, I can say grab rate #1 or grab rate #3, etc That coding was to be my next little project to write. The part I'd sent you was for when there is no shipping charge (when buyer takes items with him or herself).
A lot of the details depend on how you've already structured your tables and relationships. Here's a generalized description:
Table::RateType = ShippingRates::RateType
Set Table::ShippingRate to be a looked up value that looks up ShippingRates::Rate. When you select/enter/change the value in Table::RateType, the matching ShippingRates::Rate will be copied into Table::Rate. If there are additional factors that determine a rate, those details can be handled by including additional pairs of match fields in the above relationship.