Unlike a web browser, a "back" button could have two different functions or both in combination:
- It could take the user back to the previous layout
- It could take the user back to the previous found set
And there are multiple options for implementing one or both and the basic design of your user interface can determine which approach is best.
Just to navigate back to previous layouts, there are two basic options:
Save the previous layout names or numbers in a list. The list can be saved in a global variable or a global text field. The back button uses the data in the previous value in the list with Go to Layout and one of the "by calculation" options to go back to the previous layout, then updates the list to delete the name of the layout that was exited by this change in layouts. With care, script triggers can perform scripts to update this list automatically..
Go to a new layout by opening a new window. Then, returning to the previous layout is simply a matter of closing the window to show the window immediately below it. This can chew up a lot of resources by opening a lot of windows and you have to be careful not to edit lock records in windows hidden in the back ground, but it can be very effective on Mac and iOS (FM Go) systems if you can keep the number of open windows to a modest number of windows. And this method also returns you to the previous found set--which will be unmodified when you close a window to go back.
Returning to previous records, sort orders and found sets can be much more complicated when you keep to the same window. Multiple layouts can all refer to the same table occurrence and if so, they share the same found set, current record and sort order. Thus the set of records on Layout A may no longer be as the user left it when the user returns to that Layout from Layout B if both refer to the same table occurrence.
Some times found sets are preserved by saving a snap shot link or by putting a list of primary keys into a variable or field. If you put such a list in a field, it's possible to define a relationship that uses that field as a match field and then Go To Related Records can be used to pull up the original found set, but not necessarily in the same sort order.
Having it go to a found set make so much sense. Yes I need that much more than a specific record.
So there could be something set up to track all found sets in a session?
It's not impossible, but is something that will be very dependent on your interface design--especially work flow. It could be very simple or need to be so complex as to not be worth the effort.
I've been playing with a small "inventory" DB in FM GO on my iPhone. It lets me go to the store and see a list of all the canned goods in my kitchen so as to not buy something that I see on sale if I already have plenty in stock. Its basic design centers on a single pair of layouts (one for portrait and one for landscape orientation). Any navigation I need to do takes me to no more than three screens from that center pair of layouts before I have to back track back towards the center. With that design, I just open a new window with each tap of a navigation control and my found set remains untouched in the underlying window. To go back, I tap a control that closes the current window.
But with other designs this might result in large numbers of open windows and multiple workflow paths through the layouts might keep it from working at all. So in that case, I might need a different method. But also keep in mind that each table occurrence has its own found set. If you are moving from layout to layout and each layout specifies a different Table Occurrence--and this is very typical, you only need return to the layout to see the found set just as you left it. You only have to have a method for restoring found sets when you have more than one layout based on the same table occurrence and your user interactions with the layout may change the found set in a way that you don't want to see on the other layouts based on this table occurrence if you choose to go back to them.
With Thanksgiving coming don't forget to check if you have a found set of canned cranberry sauce.
I have started looking at the idea of a found set being the "subject matter", a good way to have Information, Topic, Subtopic, ..... Under a particular subject, and be held together by a found set. My script that can grab all Topics from Information.
Set Variable [ $children; Value:getChildren ( INFORMATION::_kp_information_id) ] Set Variable [ $i; Value:0 ] Set Variable [ $j; Value:0 ] Loop Set Variable [ $i; Value:$i + 1 ] If [ $i > ValueCount($children) ] Set Variable [ $i; Value: 1 ] Set Variable [ $j; Value:$j + 1 ] Set Variable [ $children; Value:getChildren(GetValue(INFORMATION::listall; $j)) ] End If Exit Loop If [ $i > ValueCount($children) ] Set Field [ INFORMATION::listall ; INFORMATION::listall & GetValue($children; $i) & "¶" ] End Loop
Now I am trying to configure a way to not let the user leave the found set. Is this a common practice? My Breadcrumb design is working well, but the buttons will not work with this strategy, because I am showing all records. I thought this might not be the best idea when I was creating it, however I think being new to it I just went with what seemed to get the job done. I had played with one set that does a find and another that do does Go to Record/Request/Page. Both worked but need to be looked at now if I want the Found Set to persist.
Breadcumb w Find
Set Variable [ $mas; Value:ExecuteSQL ( " SELECT \"_fk_infoparent_id\" FROM \"TOPICLIST\" WHERE \"_fk_infochild_id\" = ? "; ""; ""; INFORMATION::nuber_topic_of ) ] If [ $mas = "" ] Halt Script Else Perform Find [ Specified Find Requests: Find Records ; Criteria: INFORMATION::_kp_information_id : “$up1” Find Records ; Criteria: INFORMATION::_kp_information_id : “$mas” ] [ Restore ] Show All Records Set Variable [ $mas; Value:"" ] End If
Breadcumb w Go to Record
If [ Get( FoundCount ) < Get( TotalRecordCount ) ] Show All Records End If Set Variable [ $mas; Value:ExecuteSQL ( " SELECT \"catchrec\" FROM \"INFORMATION\" WHERE \"_kp_information_id\" = ? "; ""; ""; INFORMATION::number_descendancy ) ] If [ $mas = "" ] Halt Script Else Go to Record/Request/Page [No dialog;$mas] End If
There's way to many details missing and my memory isn't sufficient to really make heads or tails out of all that. GetChildren would appear to be a custom function.
This explains a lot though about needing to "go back" to previous found sets. Since you have a "recursive relationship" type deal here, you are moving from a parent record to a set of children and vice versa. It sould seem logical that if you can log what record was the parent, you should be able to use the relationship between parent and child records to be able to "go back" to a previous found set by pulling up the previous parent record and using it to pull up the related children--either in a found set or as records displayed in a portal.
You might also want to investigate the Go to Related records script step as a way to use the current parent record to pull up a found set of related children.
Yes, that is the project. The design is a winner all because of your advice. I am using Table Occurrences to get a lot of it done but I feel I may be relying too heavily on ExecuteSQL to deduce a lot. I have heard in some FileMaker training that you don’t want a whole lot of unstored calculation in a solution. In my INFORMATION Table I have over 10. The performance with the solution is lickety-split though. I mean it’s responsiveness and what I can see good. More importantly I want to utilize Table Occurrences for more than just basic things. When you say a Table Occurrence can store a record of found sets I don’t even know where to start. I want to explore that though. I don’t understand what that Table Occurrence will be matching on. I think I only understand when a field based on criteria is matched with another across a relationship. Like pk to fk they are equal so only show what else is in the equal’s record. How does a found set become a record? Maybe by becoming a multi-key? A group of ID’s in a return separated list? The calculation you showed me here Compare Lists Boolean? was so helpful to know about, I did not even get to use it, but it will be great in the future. I see how that might be useful in the relationship to determine if values in a found set match across the relationship. I am going to need to be more diligent in learning more about complex Table Occurrences.
Yes, it is a custom function.
Am I correct to assume that if a Table is going to store found sets it would contain at least one field that is a Multi-Key meaning a return separated list of the id's in a found set?
That is a common, but not the only way to do it.
A set of records all with a common value in one field to identify the "saved set" to which it belongs and a single ID in each record can serve the same exact purpose and in many situations can be simpler to work with.
I tend to think of return separated lists as "limited use", "secret join tables" as they can be used in much the same fashion as the join table in a many to many relationship.
BTW, "too many unstored calculations in a table" really isn't a major negative it can even be the better way to go as opposed to have a large number of stored calculations in some circumstances.
Too many unstored calculations in a Layout, on the other hand, can result in a layout that is much too slow to update correctly in many situations.