A found set is not an array. It's exactly what the name says:
It's a set of records produced by the most recent find (or similar action) on a given layout. Every layout in a given window that is based on the same table occurrence shares the same found set, current record and sort order.
To get such a grid of data, you would need something different--such as a related set of records. That would be those records in a related table that match via a relationship to the current record on your layout. You could perform a find, get a list of the primary keys for that found set and set up a relationship's match field such that a set of one row portals could then show your grid of data.
Instead of performing a find, you might use ExecuteSQL to get that same list of primary keys.
you can have a global array of containers + a parallel global array of primary keys and at the end of your scripted find, loop on found records and while in freeze window state fill the globals, then go to first record.
One significant difference between these two options:
With mine the actual record's data is displayed. Edits to it will change the data i the original found record.
With siplus's method, you display a copy of the data. Edits modify the copy, not the original
If you only need to display, not edit the data, this difference is not significant.
But one refinement of siplus's method would be to use a List of Summary field to get the list of the data from the found set and then you can loop through the list instead of the records. That might be a few eyeblinks quicker in execution.
We ± know what the user wants, less where he goes from there. That's why I suggested to capture the PK's as well, in a parallel array.
For example, when he clicks on the fifth picture he might want to go to that record inside the found count.
P.S. Summary of Containers ? I vote for it !
Siplus and I have suggested two variations of the same concept. Both would work with what you have. But a different data model would work better for managing keywords and would make it much simpler--possibly to the point of not needing any script a tall.
Record::__pkRecordID = Record_Keyword::_fkRecordID
Keywords::__pkKeywordID = Record_Keyword::_fkKeyWordID
Building a list of keywords is then building a set of related records in Record_Keyword to link many records to many keywords. Keywords, among other things can be used as the value source for a value list of keywords.
Each of the "empty fields" on your layout could be replaced with one row portals, first one is initial row 1, next is initial row 2..... Selecting a keyword (or more than one keyword to either broaden or narrow the results) could then control the matching records directly by controlling the match field used to display your records.
With this table and relationships:
On a Layout based on search, you could use a value list of keywords to select a keyword and your one row portals could refer to a field in Records to display the matching records. Clicking the portal can be turned into a button click that then uses Go To Related Records to pull up that record on a layout based on Records to show all the info about the selected record.
Thank you philmodjunk! I'm still new to Filemaker but I think I understand what you're saying. Gonna give it a try and I'll post the results when I get it.
Okay guys, I finally got it! I feel like I might have cheated a bit to get it to work and probably isn't the most efficient way to go about it but it is working and that makes me happy. Please have a look and any feedback is greatly appreciated.
Test 02.fmp12.zip 83.5 K