We could make some guesses here, but why not spell out what it is you need to accomplish that makes such a process necessary?
Maybe we can suggest a simpler approach.
Once you've performed a find to pull up a found set, a looping script with set variable or a non looping script that uses Copy All Records and that pastes into a global field can be used to set up your list of Serial Numbers.
Such a list can then be used in a portal's relationship or in a filter expression to display only records with one of the listed serial numbers.
the portal was set up to display results stored in a global variable
with some sort of key so that a subset (again stored in a variable) could be displayed
so it may for instance have a list of names with a subset of email addresses for each name
have not got a specific use as yet
but seems like a very usefull display tool
as any combination of search results can be displayed in a single portal (e.g. name and address - name and orders)
and more complex reports that need not be limited to a single subset
like i say i did not examine the demo closely enough to grasp the workings
i think the key was stored in a seperate variable
i just figured someone else must have seen it
It's a common enough technique, but the complications involved argue against using it unless you have no better alternative. That's why I asked for an explanation as to what you wanted to accomplish.
The basic concept is that if you have this relationship:
LayoutTable::GlobalTextField = PortalTable::IDNumberField (PortalTable and LayoutTable can be two occurrences of the same table.)
You put a list of ID numbers, separated by returns into the global text field and any record where IDNumberField matches any one of the values in the list will appear in the portal.
You can also use a portal filter expression with the same list of values like this:
valuecount ( FilterValues ( LayoutTable::globalTextField ; PortalTable::IDNumberField ) )
The second option works only with FileMaker 11, but you no longer have to define GlobalTextField in any specific table and it can, in fact, be a global variable instead of a table. Plus, you can combine a relationship that restricts the records shown in the portal with the portal filter expression to further reduce the list of displayed records. Example: Your portal relationship could match to all Invoice Records for a specific customer. The filter could then reduce that list to just those invoice records for that customer that meet the criteria of a find that was performed on the Invoice Records table.
It's building the list of ID numbers that can be problematic:
Create a layout based on the Portal table with only the IDNumberField present on it. Perform your scripted find on this layout or another layout based on the same table occurrence in the same window and then switch to this layout. Use Copy All Records to copy the IDNumbers into the clipboard. Switch to a layout where globalTextField is present and paste the resulting list of numbers into it. This is fairly fast, but destroys any data the user may have copied to the clipboard prior to performing this script--something that it is best to avoid if possible.
Use a looping script to build your list:
#after performing the find...
Go To Record/Request/Page [first]
Set variable [$ValueList ; value: List ( $ValueList ; PortalTable::IDNumberField ]
Go to Record/Request/Page [next ; exit after last ]
Set Field [LayoutTable::GlobalTextField ; $ValueList ]
If you use the filter option with this script, you can replace $ValueList with $$ValueList and just use $$ValueList instead of the global text field.
This method preserves clipboard contents, but can result in a significant delay when large sets of records are produced when the Find is performed.