8 Replies Latest reply on Jul 15, 2014 2:55 PM by synergy46

    FM 13 -- I need a 'trap'


      I have a little checkbook / budget program I am writing.





      Here is my Transactions layout:



      When the user enters a Check Amt ($50), that amount is subtracted from the budget remaining (A:Remaining). This works.

      But, if the user puts the cursor in the Check Amt field and presses enter again, another $50 is subtracted.


      I need a way to trap the Check Amt and then compare what is entered with that amount and only IF they are different should I proceed with the A:Remaining deduction.


      The script triggers ON ENTER don't seem to capture the 'pre value'.


      Thanks for your ideas.



        • 1. Re: FM 13 -- I need a 'trap'

          You could use another field so that, when your script runs the first time, you can fill this new field.

          Putting an IF in your script, you can check if the new field is empty or not, then execute the remaining steps or exit the script.

          • 2. Re: FM 13 -- I need a 'trap'

            synergy46 wrote:



            The script triggers ON ENTER don't seem to capture the 'pre value'.


            Do you mean the keystroke "enter" or when entering the field?


            If you want to do this with triggers you probably need to do a lot more:

            - use OnModify

            - prevent the user from changing the field if there is already a value, let them create another transaction instead of modifying an existing one

            • 3. Re: FM 13 -- I need a 'trap'

              Give the field an OnEnter and an OnExit trigger. (You can use the same script with different parameters.)


              OnEnter, capture the current field value in a $$var; OnExit, compare the current field value with the $$var's value, and proceed accordingly (and don't forget to reset the $$var …)

              • 4. Re: FM 13 -- I need a 'trap'

                onObjectSave trigger fires only the value is changed.

                But I think it is not good that every user input changes data without the input is not saved...

                • 5. Re: FM 13 -- I need a 'trap'

                  Taking a step back...


                  From the problem and the proposed solutions, it appears you are manually managing the A: Remaining field via script and SetField.


                  I think you would be better off letting A;Remaining be an unstored calc which is along the lines of :

                  Budget - Sum(Transactions::CheckAmt)


                  This would filter through the Accts relationship that you already have if my assumptions on your intent are correct.


                  No scripts or triggers needed.

                  • 6. Re: FM 13 -- I need a 'trap'

                    But a potentially very slow solution... updating through a scripted Set Field is superior for performance and reporting etc.

                    • 7. Re: FM 13 -- I need a 'trap'

                      I tried the A:remaining-sum(transactions::CheckAmt) idea and it seems to work.  However,--

                      When I change accounts the amount needs to be refreshed and new A:Remaining calculated


                      I tend to think that selecting the accounts table and then using set field to manually change the A:Remaining is the simplest...


                      Unless, you have an idea to somehow use relations and/or calculations to distribute the correct amount when the account changes?


                      Thanks for the idea.  It is interesting....

                      • 8. Re: FM 13 -- I need a 'trap'

                        oops... forgot to include this:




                        This little script seems to work well.  I just need to do something similar when the Account changes as a change to an existing account.

                        GAAP (Generally Accepted Accounting Principles) would prohibit the changing of an account and require an 'offsetting' new entry.  But, this is basically a 'single entry' accounting system so it is probably more user friendly to let them change the Account...