FIND execute as in a search engine

[ccosner]

FMP 4.1 on desktop clients, central server, on the way to FMP 6 real soon.

In the past, I have created a browser-like find (type in search terms, hit enter/return, results appear in list) by concatenating the fields to be searched into one field, indexing it, putting the user into find mode on that field. Check "pause" in the Enter Find Mode step. Works like a charm.

Well and good. However, now I would like to have users type their search terms into a GLOBAL field, hit return/enter and have the find execute (script takes global contents and runs the find on the concatenated field--one of the advantages is that they can enter these terms from any database but have it execute on another, as appropriate). As it currently stands, they have to click a SEARCH button to execute.

What am I missing here? I just know there is a simple solution. I've tried various combinations of Pause/Resume Script step, but nothing I do seems to take the event of the user hitting return/enter as a cue to continue the script. In short, argh.

[Kurt Knippel]

A basic pseudo-code script:

Goto Find Layout

Enter Find Mode [no pause, no restore]

Pause Script

User Fills out global field(s) and either clicks a button or hits the "Enter" key.

Set real Search fields to the values in the globals

Perform Find

Without seeing you script I am not sure what you are missing, but follow the above and it will work.

[ccosner]

Thanks!

Your advice helped part way, but there is a snag:

In FIND mode, users cannot type into global fields (at least, not that I know of).

So if I implement this with a regular text field called SearchField...

User wants to search, and their navigation button triggers this script:

----------------

Go to Layout (Search Layout)

Enter Find Mode (no restore, no pause)

Pause/Resume Script

Copy SearchField

Enter Browse Mode

Paste (select all) SearchField

If (SearchField<>"")

Perform Script (SEARCH)

End If

-----------------

SEARCH script takes contents of SearchField and runs FIND on concatenated field, takes them to list of results.

-----------------

In my tests this works well if the user wants to search for something. However, the layout has a navigation bar with several buttons. If the user changes their mind about searching and clicks on one of them to go somewhere, they go, but the script is still paused and in FIND mode. If I put an 'Enter Browse Mode' step at the beginning of each of the navigation button scripts, the script is still paused, with the continue/cancel option still running on the left.

Okay, I have to admit that I am setting this aside for the weekend, and it may indeed be clearer on Monday. Just wanted to post a response before the end of the day.

Chris

[BruceJ]

How about staying away from Find Mode alltogether, and just create a relationship between the global field and the search fields and have the results displayed in a portal(s)?

[ccosner]

BruceJ,

Thanks. I'm familiar with this technique, but I think it only works with one search term at a time. You can even make a link field that includes all permutations of the field, so that users can type just a few letters and see all entries that begin with those letters.

Could you give me an example of the programming in a books database (with author and title) where you could type "berry mark," tab, and get back "Huckleberry Finn by Mark Twain" in a portal? My current solution does this for several fields, but users have to click a button. I'm being nitpicky, I know.

[BruceJ]

You can do it...

Create a calc field that combines the fields:

Calc Field:

Substiute( Title & Author, " " , "P" )

P = Paragraph return. You can get a lot fancier of course. This one will return all the "Mark"s inlcuding Mark Twain, but will not actually narrow the search with more criteria.

To Narrow the search, I'd use a calc field that returns progressivley more of the Title and Author..

So that the result will look like:

M

Ma

Mark

Mark T

Mark Twain

H

Hu

Huc

Huck

Huckl

Huckle

Huckleb

and so on.....

I'd actually make two calc fields like the above, except one for author and another for title and then in the "search" layoutt show two portals, that way its clear to the user if its the title or author that are returned.

I'll see if I can put together and example latter on.

[ccosner]

Hmmm

I used author/title as an example. My search runs on many more fields, so multiple portals are out of the question.

The example you give works for partial completions of the word starting with the first letter, but I I'm anticipating even partial words and "misrememberings." So if a user somehow managed to just remember that there was a berry in the title and the author's name started with Mark, or even rhymed with ark, they might be able to pull up the record by typing say, "berry ark". With the system you describe, which is groovy nonetheless, you have (in simplified form)

Left(Author, 1) & "P" &

Left(Author, 2) & "P" &

Left(Author, 3) & "P"...

Left(Title, 1) & "P" &

Left(Title, 2) & "P" &

Left(Title, 3) & "P"...

in the link field.

But if the user only remembers "berry" it still won't pull up Huckleberry Finn.

I'm sure that one could get around this with the Middle() function and an enormous stack of variations (to bring in uckleber, ckleberr, kleberry, etc.,) but then too many records would appear in the portal because there would be too many matches. Alternatively, you could parse out the words as well:

Left(Leftwords(Title, 1), 1) & "P" &

Right now I'm concentrating on the FIND mode angle because it does allow these partial spellings without the need for tons of additional programming, and it's ideal for searching a concatenation of fields.

--Chris