Create a global field, put it in the Header part of your List View layout, and attach the following OnObjectModify script trigger:
If [ IsEmpty ( your_table::your_global_field ) ] // If the global field is empty, all records will be shown and the script will exit
Show All Records
Set Error Capture [ On ]
Perform Quick Find [ your_table::your_global_field ]
If [ Get ( LastError ) ≠ 0 ] // If there are no matching records, a dialog is shown
Show Custom Dialog [ "No matching records" ; "No matching records" ]
Show All Records // after Quick Find goes to the first found record, this step then shows all the records in the list, so that you're not left with just the "found set"
Go to Field [ your_table::your_global_field ) ] // this step returns the cursor to the global field after each keystroke
Hope this helps.
Thanks. That works if the list is to show all records. I'll keep that in the bag of tricks.
I won't go into all the details of why this won't work in my ap. I'm just giving up on this and will work around it somehow. I'm just amazed that FM doesn't have something exactly like Find but that doesn't impose a filter. Just do exactly that, find. Ah well. Maybe next version.
There's also a way to use Go To Related Records to do this without affecting the current found set, provided the record with the specified name is part of that found set.
I assume this applies if you're going from one table to a related table? To make a hypothetical, if I have a record for each sale and a layout that gives details, then I want to switch to a layout that uses a self join to eliminate duplicates and just lists one line for each salesman, eliminating the records for all sales by that salesman other than the first found, and I want to go to the line in the list view for that salesman. I have a salesman key field so regardless of which of his records is the first found I should be able to find him by doing some sort of key-fileld=$$saved-salesman-key, but it may not actually be the same record as the sale I was viewing in the detail view. What I'm using at the moment is a Perform Find/Replace just doing a find. It works. I have to put the key field on the form and then hide it, but it works.
Go to related record works from one Table Occurrence (box in Manage | Database | relationships) to another. Thus, you need two table occurrences, but the two can actually refer to the same data-source table.
lets' call your table "Details". Define a global field in it, gSalesManKey. This is field, not a variable.
Define a relationship:
Details::gSalesManKey = SelectedSalesManDetails::SalesManKey
Now this script:
Set Field [Details::gSaleManKey ; $$Saved_SalesMan_Key]
Go To Related record [from table: SelectedSalesManDetails ; Using Layout: <Current Layout>]
Will make the first record with the value copied form the variable the current record. If this record is in the current found set, the found set will not be modified. If it is not in the found set, you'll get all records with the first related record the current record.
I think there's a complication here which is part of why I had a hard time with this. That I have a 2nd instance of the table and a relationship used to eliminate duplicates, and my list is based on that 2nd instance, and to combine that function with the functionality of this other instance you're describing and make use of that relationship, I'm not sure how all that works together.
This is for a recurring bowling charity benefit. There are team captains and some captains have more than one team so the unique key is captain name & team name. I also make a "partial key" which is just the captain name which may not be unique if they have multiple teams.
So I have one view with all the details of that captain, team, a portal of contact notes, etc. I have a button that goes to another layout that is a list of captains with the duplicates eliminated so there's just one line for each captain. It should jump to the current captain so the user can see where they are in the list and just click on the next one to go to its detail. So this list view is what has a second instance of the table and the relationship set up to eliminate dupes.
So what I've settled on now is in the detail view I set a variable with the partial key value, go to the list, do the Find to eliminate dupes, and a sort, then do a Find and Replace (with no replace) to find a record with that partial key from the variable.
As an extra little trick I want the selected line to be in the middle of the viewable portion of the list. So when I first find it I save its record number, then I jump to record + 12, which forces the list to scroll down some, then jump back to the record I really want. If the record happened to be near the bottom (less than 12 from the end) no harm. It just scrolls down to whatever the last record is, then goes back to my desired record, which might be 2 lines or whatever up from the bottom.