8 Replies Latest reply on Dec 21, 2011 8:10 AM by mgores

    FM GO: Refresh window script very slow/iPad keyboard control?

    mcthc

      Title

      FM GO: Refresh window script very slow/iPad keyboard control?

      Post

      A script that works perfectly in Filemaker Pro is painfully slow in Filemaker Go.

      I used PhilModJunk's Enhanced Value Selection technique (http://forums.filemaker.com/posts/3156a8d72a) to simulate the auto-complete feature, but one that searches multiple fields (first name and last name).  This is accomplished using a global search field with a script trigger that OnObjectModify refreshes the portal window with results that conform to the letters typed in the search field.  

      The script has the following steps:
      -commit records/requests
      -Refresh Window (flush cached join results)
      -Set Selection (CONTACTS:SEARCH; Start Position: Length ( CONTACTS:SEARCH ) + 1; End Position: 0)

      In Filemaker Pro this works beautifully and the auto-complete is instantaneous (works just like the search box in Apple's Address Book).  In Filemaker GO it's painfully slow.  The script takes 2-3 seconds to process each letter typed, and the iPad's keyboard disappears as the script executes then comes back up to allow the next letter to be typed in. Too slow and the keyboard popping up and down with each keystroke is very disconcerting.

      Here is a sample sequence:

      Type "A"
      Script trigger fires, keyboard disappears
      Portal refreshes with all records containing "A"
      Keyboard pops up 

      Type "D"
      Script trigger fires, keyboard disappears
      Portal refreshes with all records containing "AD"
      Keyboard pops up 

      Does anyone have any suggestions for speeding up the script in FM Go?

      Is there a way to prevent the iPad keyboard from popping up and down during script execution?

      I'm happy to share the file if it would help.  Thank you!

        • 1. Re: FM GO: Refresh window script very slow/iPad keyboard control?
          philmodjunk

          Recent discussions here would suggest that the "flush" option on Refresh window is the likely culprit. Unfortunately, I don't know of a way to get the filtered portal to update on a keystroke by keystroke basis if you don't.

          Would really love to see a way to eliminate that parameter when using filtered search portals...

          • 2. Re: FM GO: Refresh window script very slow/iPad keyboard control?
            mgores

            I haven't tested it using the iPad yet, but have found the trick using another cartesan relationship in your portal to a "refresh" field to work well to avoid the refresh flush step.

            You need to create a field in your source table for refreshing the relationship.  I just set up a text field in the source file called refresh.  Add it to your relationship as a cartesan join to any field in your table.  Then setup a script

            Set Field [Source::refresh ; Source::refresh +1]

            Commit record

            Go to Field [yourfield]  //this is the global search or matching field you are typing in

             

            Update:  I tested this on the iPad and it still makes the keyboard go away and pop up.  It is pretty quick but definitely noticeably.  Am pretty sure it is the Commit record, Go to Field steps that make the keyboard go away and come back.  Need to find a way Commit the record without having the keyboard disappear.

            • 3. Re: FM GO: Refresh window script very slow/iPad keyboard control?
              philmodjunk

              Great suggestion here!

              Have you tried this with a Freeze Window step at the start?

              Wonder if that will keep the "twitch" from happening in GO...

              Now to play with my demo file to see if I can remove the Refresh/Flush steps from it...

              • 4. Re: FM GO: Refresh window script very slow/iPad keyboard control?
                mgores

                just tested it.  The Freeze window step does not affect it, the onscreen keyboard still goes away when the commit record step executes.  It is faster than it was with the refresh/flush method though.

                I tried using Set Field [search ; search]  instead of the Commit and Go To field steps.  This works as well on the computer, but still results in the keyboard on the iPad disappearing momentarily.  (it does shave another step off of the script though Smile)

                Now it is just

                Set Field [Source::refresh ; Source::refresh +1]

                Set Field [main::search ; main::search]

                • 5. Re: FM GO: Refresh window script very slow/iPad keyboard control?
                  philmodjunk

                  Interesting. And I've just uploaded an updated demo file. (has same download link as original).

                  May need to test some more and upload yet another update!

                  (Wonder what happens if you leave off the +1?)

                  • 6. Re: FM GO: Refresh window script very slow/iPad keyboard control?
                    mgores

                    (Wonder what happens if you leave off the +1?)

                    Eureka,  that did it.  The new script

                    Set Field [Source::refresh ; Source::refresh]

                    Set Field [main::search ; main::search]

                    updates the portal and does not make the keyboard twitch on the iPad.  I originally assumed you had to change the refresh field, but apparently the Set Field step alone is enough to refresh the relationship, just as the set field for the search field is enough to commit the record and keep the cursor in place.

                    • 7. Re: FM GO: Refresh window script very slow/iPad keyboard control?
                      mcthc

                      GENIUS!!!!

                      No more keyboard twitch on FM Go. 

                      Thank you so much Mark and Phil!  You are my Filemaker heroes Laughing

                      • 8. Re: FM GO: Refresh window script very slow/iPad keyboard control?
                        mgores

                        mcthc

                        There is a thread in the filemaker forum where we trimmed this down even further.  By setting the Source::refresh field to be an autoentered calculation using main::search    we got it down to a single step,  just the Set Field [main::search ; main::search] 

                        As soon as you type a character in the search field, the script trigger Sets the search field (effectively commiting the record and placing the cursor back in the field).  Changing the search field causes the refresh field to change because it is calculated from the search field, which causes the portal to refresh since the refresh field is part of the relationship.  While I'm not sure, I have heard it mentioned that these portal refreshes are fastest when both sides of the cartesian relationshop are globals, so using Source::refresh and main::search as the related fields for the portal should be the optimal way to go.

                         

                        Thanks for posting that question, I have been using the refresh/flush extensively in some of my solutions, but we are just now introducing iPads and we hadn't bumped our heads on that yet.