1 Reply Latest reply on May 29, 2015 7:06 AM by philmodjunk

    Dynamic Filtering for portal

    zinny

      Title

      Dynamic Filtering for portal

      Post

      Hi, 

       

       

       

       

       

       

      I am working on a system where clients are displayed in a portal that sits in a developer layout. The link to the developer layout is a fixed number.

      I want to be able to filter the portal based on a search global field (a global field in the developer table). I have a calculation field in the client table that does a pattern count of the client name (returning a number of times the few letters entered in the search field exist). The clients in the portal are matched against this calculation in the filter Clients::patterncount >0. 

      But it doesn't naturally filter, it only seems to filter after opening up the manage database and changing something and then saving.

      I have tried putting the whole calculation in the filter window but this doesn't seem to refresh either.

      How do I get the filter to apply as the user types in more letters, reducing the number of entries in the portal as it gets more specific?

      Thanks

      FMP13

        • 1. Re: Dynamic Filtering for portal
          philmodjunk

          This issue normally arises when the field used in the portal filter expression is a global field. If it's not a global field, you may just need to commit records after each change of the field used in the filter expression. This can be scripted and performed from a script trigger.

          If that fails, the trick for FMP 13 or older is two fold:

          1) include the Cartesian Join Operator in the relationship
          2) "goose" the relationship by using set field in a script to update the value of the match field on the layout's side of the Cartesian Join each time that you update the value used in the filter.

          You can also use the Refresh Window [Flush Cached Join Results] script step, but in a number of cases, this can produce unacceptable delays waiting for FileMaker to complete redraw the window. It can, however, be a way to confirm that your filter is filtering correctly and just needs to be updated.

          For working examples of the first method, see the search portal examples found in "Adventures in FileMaking #2 - Enhanced value Selection".

          In FileMaker 14, there's a new script step: Refresh Portal that claims to do the same job, but I haven't tested it yet...