7 Replies Latest reply on Sep 18, 2014 9:29 AM by philmodjunk

    Concept of "going back" or saving layout "states" in FMP

    ShaneB

      Title

      Concept of "going back" or saving layout "states" in FMP

      Post

      In my FMP solution, my users are frequently looking at long lists (1000+) of records, switching views to other groups of records via a search or other function, and then going back to the original list of records. They then have to use the scroll bar or page down to get back to where they were before. Or, more frequently, they run a search to create a new found set of records, do something that changes the layout or found record set, and would like to quickly get back to where they were before without running the original search again.

      Is there any kind of way to create more efficient ways of moving around and working with records in ways like this? Something like a web browser, when you hit "back" you go back to the location on the page you just were on. Are there ways of popping up new windows with different layouts that wouldn't overwhelm the users over time? I'm curious what methods are often employed to solve these types of problems.

        • 1. Re: Concept of "going back" or saving layout "states" in FMP
          philmodjunk

          There are a number of techniques that you can consider:

          a) You can save the name or number of the previous layout in a global field or global variable. Such a field or variable can even store a series of names or numbers in a list as a "trail of bread crumbs" that allow users to retrace their steps through a series of previously visited layouts.

          b) you can "preserve" found sets through a number of techniques.

               1. You can open a new window when the user needs to see a different "view of the data". When the user closes that window, they are returned back to the previous window and it's found set, current record, scroll position is unchanged.

               2. You can "hide" window not currently in use by moving it to a set of negative coordinates to reduce "window clutter".

               3. But multiple windows can get pretty ugly on windows systems, you may want to use a different approach

               4. You can set up two layouts that are based on two different Tutorial: What are Table Occurrences? that have the same data source table. If you do, the found set, current record and sort order on each layout will be independent of the other.

                5. You can "save" a found set by storing a list of the records' primary key values in a field or variable. You can then use a relationship with a field loaded with that list and Go to Related Records to recreate the found set (though you'll then need to sort them.)

               6. You can "clone" a found set to another layout and/or window using Go To Related Records. The trick is to specify the current layout's table occurrence as the "table" and specify "show only related records". Your specified layout need only have the same data source table in common with your starting layout for this to work.

              7. If you put the primary key of the current record into a global field that you set up as a match field in a self join relationship to another occurrence of the layout's table. You can "save" the current record to it and then Go to Related records with out the "show only related..." option can be used to make that record the current record once again, scrolling the window to bring that record back into view.

             8. If you use the scripted find techniques shown here: Scripted Find Examples, your most recent find criteria is already stored in global fields and you can run the script again to recreate a previous found set. You could even copy that criteria into a table as part of a "bread crumbs" set up where you use the global field or variable from a) to get back to the layout and this save criteria to then recreate the found set.

          Caulkins Consulting, Home of Adventures In FileMaking

          • 2. Re: Concept of "going back" or saving layout "states" in FMP
            ShaneB

            I currently use a "tab" setup that act as buttons that switches layouts between different types of records. However, once you move off of the current layout and found record set, if you go back you are shown all the records of that type again. Could I instead give each of these tabs separate windows that have IDs, and the tab button instead switches between windows and moves windows around using coordinates? I wasn't aware window coordinates could be specified, but that seems like an interesting option. This would be an interesting first step.

            • 3. Re: Concept of "going back" or saving layout "states" in FMP
              philmodjunk

              However, once you move off of the current layout and found record set, if you go back you are shown all the records of that type again.

              This is not necessarily the case. It depends on the design of your layouts and what your users and your scripts do to manipulate the records that make up a found set. In fact, I would not expect to "see all records of that type" like this upon returning to the layout unless some other user action or interface design feature interfered to change the found set.

              • 4. Re: Concept of "going back" or saving layout "states" in FMP
                ShaneB

                Phil: What I meant by that is that in my design, each tab button runs a script that filters for a particular type of record and displays it on the appropriate layout. If you hit another tab button it displays a different type of record on the appropriate layout. If the tabs switched between different actual windows, this would retain their states rather than refreshing them every time a tab is clicked.

                • 5. Re: Concept of "going back" or saving layout "states" in FMP
                  philmodjunk

                  Yes, or you can use two different layouts, each based on a different occurrence of the same table.

                  • 6. Re: Concept of "going back" or saving layout "states" in FMP
                    ShaneB

                    Switching layouts is much less cumbersome and clumsy than switching windows, I have found after some experimenting. However, when I switch between layouts the scroll bar position resets. I'm guessing I can't avoid this, can I?

                    • 7. Re: Concept of "going back" or saving layout "states" in FMP
                      philmodjunk

                      Unlike changing windows, you can't avoid this, but you might be able to mitigate the result:

                      If you put the primary key of the current record into a global field that you set up as a match field in a self join relationship to another occurrence of the layout's table. You can "save" the current record to it and then Go to Related records with out the "show only related..." option can be used to make that record the current record once again, scrolling the window to bring that record back into view.