4 Replies Latest reply on Sep 9, 2015 11:57 AM by raykennedy

    Disabling vs Hiding Fields on Specific Conditions

    raykennedy

      I would like to have a field or a couple of fields disabled and prevent user input based on conditions of another value from a field. I know I can hide the fields using the hide object attribute in inspector but I don't want them to completely disappear, just prevent user input. I know you can do this by removing the browse mode in the inspector on this but I want this to be dependent on some other conditions. Did not see anything that I could use to script the fields browse state. It would even be nice if I could create a style change on them so they appeared to be disabled but still showed their placement on the screen and value with them grayed out.

       

      Here is my thoughts on how I would handle this. Just wanted to see if there is another way that is more efficient. This is just a simplified condition for illustrating what I am attempting to do.

       

      Field-A is the one want to hide if x = y;

      Field-B is the one that will show when Field-A is hidden in order to mimic a disabled Field-A
      Field-B could simply be calculated to take the value of A and I would just change the style of this object to give an inactive appearence and remove the browse mode from it in the inspector.


      # On the Field-A Ojbect using hide object attribute

      IF [ x = y]

      hide Field-A

      END IF

       

      # On the Field-B Ojbect using hide object attribute

      IF [ x ≠ y]

      hide Field-B

      END IF

       

      Any thoughts on best way to handle this.

        • 1. Re: Disabling vs Hiding Fields on Specific Conditions
          Mike_Mitchell

          You're likely overthinking this. There's no need for a second field. You can handle this requirement with a combination of Conditional Formatting and Script Triggers.

           

          Conditional Formatting can be used to change the appearance of the field when the "lock" condition is true.

           

          You can use either the OnObjectEnter or OnObjectKeystroke Script Trigger to run an appropriate script when the user clicks / tabs into the field, depending on whether you want the user to be able to copy the contents out or not. (Yes = OnObjectKeystroke, No = OnObjectEnter) The script simply kicks the user to the next field in the tab order and optionally provides an alert to the user that entry is forbidden.

           

          HTH

           

          Mike

          • 2. Re: Disabling vs Hiding Fields on Specific Conditions
            raykennedy

            Mike, thanks for that. That is 100% more efficient and I am not sure how I overlooked conditional formatting especially since I was just using it for portal records.

             

            The script trigger you mentioned seems to be a really good way to handle the input control. I appreciate the input, very helpful.

            • 3. Re: Disabling vs Hiding Fields on Specific Conditions
              Mike_Mitchell

              You're welcome.

               

              Just be aware that such interface-based contrivances are not a complete solution. A user who has access to import records, for example, can still override them. So you have to account for that.

               

              Further, they're specific to the particular layout in question. So if the user can somehow access the field through another layout, then he can bypass the "lock" despite the condition.

               

              Therefore, you probably want to take a look at schema-level validation through the Manage Database dialog if you want a higher level of control.

               

              Cheers.


              Mike

              • 4. Re: Disabling vs Hiding Fields on Specific Conditions
                raykennedy

                Mike, Thanks. That is a great point. Still new to filemaker pro and learning the flow of it. Use to mostly web programming via php, mysql, javascript, html etc. Loving the flexibility this offers, more powerful than I originally expected which clearly is coming with a deep learning curve.

                 

                In this case, this is more of a one time user experience on one particular layout so the solution you provided fits perfectly but thanks for the direction when considering the solution for other options.