A portal continuously reflecting records that match what you type in a search field is quite a common thing. Depending on the number of records in the related table, there are various strategies. Your request seems odd, though.
I'm attaching an implementation working decently when the number of records is 5000, maybe it can fit your bill.
People.fmp12.zip 664.0 K
Thanks for the quick reply. My request seems odd because I didn't think through the problem before asking the question. What I'm after is typing some letters in the text box and as I type, drill down to the records in the portal which contain the letters I typed (of course in the particular portal field). I mis-stated the question. It's a find that I'm trying to accomplish. I will look through your sample solution and evaluate it. Thanks again...
Thanks for the sample solution. This is a good plan B if I can't do what I really want, which is to simply scroll the list to the first record that matches the find text. It's ok to just begin with that text, rather than contain that text. I didn't really want to constrain a found set so the portal ONLY shows the matching records.
Is there any way to simply scroll to the desired record(s)?
Example: If I type "SM", I would see the list scroll down to show:
without actually constraining the found set.
In addition, I don't actually want to SELECT the first found record, only scroll the list to show it, and all records following...
What you are describing is the same behavior that happens in a drop down list. If the list is showing then it will scroll to matching results for what you typed - starting from the first letter of the word only ( I.e no substrings); but the value won't actually get entered into the field until you click it. A draw back though is that you don't see what you are typing. It's just like as-you-type searching in many other 'list' areas of FileMaker: the relationship graph, function lists, script list, etc.
WHat problem does 'selecting' the portal row create? It just becomes the current row/record... Shouldn't cause any harm.
Edit, Preferences. On the General tab, there's a User Interface Language.
Is this what you're looking for?
I think this reply was intended for another thread. I saw one asking about changing the default language.
If there was a way to have a drop-down list always open, I'd use that. I'm from the .Net world, where we have combo boxes and list boxes, so that would work for me.
My plan was when the user scrolls the portal to the name they want, then clicks the portal row, it would bring up the record in the layout. I do this all the time. I just wanted a shortcut alternative to having to scroll hundreds of records down before finding the record I want in the portal.
If each row is selected as it's scrolled to (while doing the "search"), it would add a lot of overhead to the operation, especially if I'm running from a server.
So again, is there any way to scroll the portal by script step instead of clicking in the scroll bar, or dragging up the list itself?
I tried the following:
On Object Enter trigger for the portal, I set a global $$ACTIVE_ROW to Get ( ActivePortalRowNumber ).
According to data viewer, this works fine.
Then in the find text box trigger (on change), once I type in a letter (or more letters), I loop through the portal rows until the name field in the portal row starts with the find text, then I set the focus back to the find text box and exit the trigger.
According to the data viewer, this also works fine, as the global variable has the proper row number.
Here's my concerns:
1: Although this happens fairly immediately with a handful of records, I'm afraid there will be a noticeable lag if I have hundreds of records.
2: When focus goes back to the find text box, the active row visual state of the portal is no longer there, so it's not clear to the user that the row is actually selected.
I tried putting a graphic on the portal row, with the Hide When expression as follows:
Get (ActivePortalRowNumber) <> $$ACTIVE_ROW
This should hide the graphic for all but the active row in the portal, but instead the graphic appears in all rows.
Maybe I'm going about this the wrong way, just to duplicate a functionality I had in my Access version of this app. Perhaps I should just go with SIPLUS's method, which constrained the found set.
Any further suggestions? Thanks so much in advance...
Your problem seems to be an academic one, instead of a practical one.
What does that even mean? The problem is quite practical. I'm trying to migrate a working Access application into a FileMaker solution. A feature that the customer has had for years is as I described. Just trying to duplicate it.
It may be that I just want to filter like you suggested for more efficient processing.
Thanks, schamblee. This article was great. Turns out that was a second more powerful type of search, but the author's first article, which was linked there, fit the bill perfectly. In my case, it was even simpler, as I only need to filter by last name. I don't even need the custom function, I can put my criteria in the portal entirely.
I can't figure out which will be better, this method from the article you pointed me to, or SIPLUS's method with the SQL functionality. I will need to wait until I enter several hundred records to test them against each other. For now, I'm going with this method. Thanks everybody, for responding.
[In reply to posting #7 above...] It depends on what you mean by having the drop-down list always down. While typing, yes, the list will always be displayed, and the nearest matching entry will scroll into view. It behaves the same as doing type-ahead-searching in most HTML web forms. So a list of countries, once you start typing, will scroll to what matches first, while the list remains visible.
Is this list an exclusive list? I.e. the user can only enter data that comes from the list? If so, then a pop-up object is probably what you want. If you want them to be able to enter anything they type, then a drop-down is more perhaps more what you want. The issue I sometimes have with a drop-down, however, is that to do that free typing, they have to click a second time into the field. The first click just shows the list and when they start typing it does the type-ahead-search behavior.
Thanks for the tip, justinc.
This is an exclusive list. They can only pick a student from the list. A ListBox would be perfect for this, because it would act like a popup list, but would always show the records. I don't think FileMaker has that, however. So I have a self-join portal, and with the proper scripting, a search text box narrows the filtered list down as you type. Then when I pick one of the remaining items, my scripting causes it to go to related record and show it in the layout, and also clears the search box.
The only thing that's not happening, is returning to the portal to show the proper record. Hence the original question in this thread. I wish I could jump to the proper record in the portal. Well, not really jump to it, just cause it to scroll into view. This feature would be a nice-to-have, not a need-to-have.