4 Replies Latest reply on Apr 19, 2012 4:51 AM by Vinny

    Revert Field to Last Value

    Vinny

      Title

      Revert Field to Last Value

      Post

      I have a layout with 2 fields.  A name field, and a type field.

      If the user changes the type (pop up menu), I have a script to check if the record is in use - in which case I block any changes.

      Checking if the record is in use is all set and it works.  The problem I have is reverting the type field back.  I would like to avoid having to revert the whole record if possible, because I'll alloy changes to the name at any time.

      I was thinking that when the user enters the field I would "grab" the existing value, but the script triggers don't work that way for pop ups.

      Any ideas?

        • 1. Re: Revert Field to Last Value
          philmodjunk

          If another user is editing the record, Filemaker locks the record against changes by other users for you and attempts by other users to modify the record trigger an error message to that effect. If the record is so locked, the user will be prevented from making a change in the pop up menu field as well as any other field from the same record.

          If you want to capture the previous value of the pop up menu in a variable, you can enter the field into the option script parameter box with the OnObjectEnter trigger.

          The trigger can perform this step:

          Set Variable [$$PreviousValue ; get ( ScriptParameter ) ]

          To store that previous value in a global variable. Then another script can use Set field with this variable to revert the field to its original value.

          • 2. Re: Revert Field to Last Value
            Vinny

            Phil,

            I'm not concerned with simultaneous users.  This is a layout for a subcategory.  It has a name, then it has a "type" which is basically the category.

            If the subcategory is in use, we don't want any user to be able to change the category it is a subcategory of.  If they did change it, then all my references in other related layouts (in pop ups) will not longer show the value, but only the ID (as it is no longer part of it's value list).

            Therefore, I'm trying to prevent the user from changing it once it's in use.  If it's not in use, the the user can change it.

            I need to do something similar with the delete script, but in this case, I needed to revert this field (only).

            I think your script parameter trick will work.

            For FM13 I would only hope that there is more sophistication built into the drop downs and pop ups....

            Thanks!

            • 3. Re: Revert Field to Last Value
              Vinny

              After messing around with this a little, I think I found an issue.

              I was in the field above the pop up, all the text was selected/highlighted, and I accidentally dragged the text into the pop up.

              The pop up was updated with this text.

              This kind of bothers me because:

              1) Now I can't capture the previous value

              2) It violates the setting "Allow Entry of Other Values" which is currently unchecked.

              Not very happy about this one.

              Maybe I'll have to peer down the relationship chart, get the ID of the category in use, and use that instead of trying to get a previous value.

              • 4. Re: Revert Field to Last Value
                Vinny

                After more investigation, I found the option to disable drag and drop text in the preferences dialog.

                However, I'm still surprised that script triggers are not fired with the drag and drop, even though it changes the value of the field....In my opinion, this is a bug.  Unless I am missing something...

                For my solution, while I am "looking" through the relationships to check if the subcategory is in use (before allowing a change), I also grab the category, and then use that for the setting to revert to.

                With this solution, I assume that there will be only one category value in the related tables, but I think that is a safe assumption based on the fact that it can't be changed if related records are present.

                I'm going to run with this for now...until I find another issue with it that is.