The simplest would be not to use a portal at all. If you perform your find directly on the layout, the find will pull up a found set of those records and you can scroll (list or table view) or click (Form view) through the resulting found set.
To show search results in a portal depends on the type of search you need to perform.
If the actual criteria you will specify is fairly limited, you can set up either portal filters or match fields in the underlying relationship that use fields you place on the layout for the user to select or enter data that then controls what appears in the portal.
If the searches are very "free form" where the user might specify any number of different types of criteria, a script can capture the ID numbers (auto-entered serial number field in most cases), put them as a list of values in a text field that is used as a Match field in the portal relationship to show the results of your find.
If you still want to use a portal, give some examples of the type of searches you will need to perform and I can use one of the above two approaches to describe the method in more detail.
Ok, thanks. Unfortunately the portal is the only way I can do this.
To describe it better I've attached a screenshot. The user clicks on a button to toggle search mode. He can enter his criteria into the field which he wants to search and hit enter to get the results.
Example would be searching for entries of a certain date: Click "Search" button, enter date into the date field, hit enter.
Unfortunately the portal is the only way I can do this.
And why is that? Not trying to start an argument, but your layout screen shot doesn't indicate to me that you have to use a portal. The upper block of fields, for example, could be placed in the header of a list view layout.
But working with the portal idea...
You do not use find mode for this method. It all takes place in Browse mode.
Put a global date field, LayoutTableOccurrence::gDate on your layout or on a differnet layout that you pop up in a new window for selecting/entering a date.
Use this field as a match field in the relationship on which the portal is based and any date you enter/select will determine what records appear in the portal. But this limits your searching only to specifying a date.
If you also need to specify other criteria, a portal filter can be used instead that compares against multiple criteria fields to determine what related records will appear in the portal. Here's a sample portal filter expression that let's you specify a date, a minimum amount, or both:
( IsEmpty ( LayoutTable::GlobalDateField ) or LayoutTable::GlobaldateField = PortalTable::DateField ) AND
( IsEmpty ( LayoutTable::GlobalMinAmt ) or LayoutTable::GlobalMinAmt < PortalTable::amount ) )
Filtered Portals, however do not automatically update when you change a value in one of the filter fields unless you include those fields in the relationship using the X operator instead of =. The following relationship would work with this example, showing all records in the table if both filter fields are empty:
LayoutTable::GlobalDateField X Portaltable::AnyField AND
LayoutTable::GlobalMinAmt X PortalTable::anyField
It's primarily visual design requirements (e.g. the footer row would be stuck to the bottom of the window, color gradients in the body etc.) , but there is also other stuff going on on that layout.
It is designed for users who don't know anything about FM, so it has it's own navigation in the header (users won't see the FM toolbar). The top priority is simplicity, hence no popups or other windows for the user. Actually, the only thing I am allowed to do is to toggle search mode with a dynamically labeled button. In bowse mode it shows "Search", and in search mode (or when browsing search results) it shows "End search".
Everything works well so far but the portal gives me such a headache now.
Your explanations about matching fields in the relationship are very interesting. They brought me to this idea: (1) Use a = relationship. (2) Utilize a script trigger to flag every record of the search results with a random number. (3) instantly apply this number to all records of the 2nd occurence.
The second occurence will then only show the records with the matching numbers which are the search results.
By using a new random number every time, I will never have to "set back" the flag field. It would work continously as long as it is triggered correctly. That means, also trigger the script when switching to "show all records". In case this would work, I hope it doesn't bring up a performance issue.
I do not understand why your design options are so limited. "Actually, the only thing I am allowed to do is to toggle search mode with a dynamically labeled button." Really? It's like trying to row a boat and then only being allowed a single oar.
Your 2nd option seems needlessly complex. How would you flag every occurrence of a record matching that valule? Loop through records? Might have a significant delay if you have a lot of records to loop through. And when shared over a network, one user's search will collide with that of any other user also searching records (Each might end up trying to assign a different random number to the same record).
Instead, you can build a list of Unique record serial numbers in a global field or variable. With the global field, the field can be part of a relationship to list matching records. With a variable, you can incorporate that variable in your portal filter expression.
Ok, I got it this way now by using a script trigger on switching mode.
- Add a field "id_filter"
- Generate a unique ID like a random number on every search and place it into id_filter for all found records (trigger a script on switching mode and use "replace content" to only fill in the found records)
- filter the portal with Table1::id_filter = Table2::id_filter
The only thing that doesn't work is when you use the "show all" button in the toolbar because the script doesn't fire (no trigger). But, since I don't use the toolbar, I'm fine with that.
And if this is a database that has multiple users--all searching for records at the same time, it will fail as I have previously noted.
There won't be multiple users simultanously, fortunately. :)