5 Replies Latest reply on Jul 9, 2010 8:22 AM by philmodjunk

    drop down trigger trouble



      drop down trigger trouble


      I have a form with a drop-down field ("shipping")(w 3 options now contained) to which have set an OnObjectModify trigger script. The form only contains two fields (both with field behavior 'browse mode' checked), except has related portal into which I can go to add/delete records). Both parent fields defined to perform as drop-downs.

      When I update the "shipping" field the 2nd field automatically becomes active (its corresponding drop-down appearing), but the trigger script is never called. The 2nd field becomes active with or without presence of triggers. Why? More impt, what am I missing here? How can I cause trigger to fire after update chaining set of responses?

      I need the first field's update result to instruct a value for a ship cost field, then calc sales tax and total cost.

      I've experienced triggers working before, and was thrilled when they became available in FM! Need to figure why trigger isn't firing and what to do to remedy


        • 1. Re: drop down trigger trouble

          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.

          • 2. Re: drop down trigger trouble

            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

            Perform Script("CalcOrder")


            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

            Thanks Phil

            • 3. Re: drop down trigger trouble

              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.

              • 4. Re: drop down trigger trouble

                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).

                • 5. Re: drop down trigger trouble

                  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.