Need inspiration for "interactive" find command

[GibsonCRG]

Hello FM'ers - I've come across an obstacle, and I fear I just haven't gotten the right basic level of abstraction in my mind to tackle this.

I have a list of records displayed in a standard layout, using a "find" criteria (e.g., all "active" issues). Now, each issue has an owner and a title. What I'm trying to do is to have a control of some sort in the header area of the layout where a user could select an item from a value list based menu to execute a "find" based on that value.

For instance, when I first display my list, I see ALL the records by all owners (but just the "active" ones); then I go to my "control" in the header, select "Chris", and now I see all the records that are both "active" (from the original find) and also owned by "Chris" (by a new find, based on the value I just chose).

I've run into a number of snags, but mainly it's that I can't seem to figure the right way to put this sort of control up in the header section - I'm presuming since it's not part of any given record.

Any inspiration from the gurus would be appreciated.

Cheers!

..Chris..

[danjacoby]

Why do you need something (and what, exactly do you think you need) in the Header part?

If you're doing a find, do a find.

If you're trying to sort records by owner, sort 'em by owner.

If you want to see records grouped by owner, there are (at least) two ways to do this:

1. Create a related "owners" file, with each owner being one record, and relate the owner field to the owner field in the original file. Then create a portal based on this relationship. This is best for seeing the records (especially in Browse mode), and you can add records from the portal as well.

2. To print (since printing from a portal has many dangers), in the original file create a leading sub-summary part when sorted by owner, and put the owner field in it. Then when you sort by owner and print, the sub-summary part will lead each group.

[GibsonCRG]

Why do you need something in the header part?

What I'm after is a bit of an "interactive" browsing experience for users that are using this database as an end-user application, and don't have the familiarity with FileMaker to execute "Finds" on their own.

What I'm really trying to do here is to allow the users to dynamically "filter" the data being displayed to them, rather than asking them to sort ALL the records by user and then scroll down to wherever their name happens to fall.

I'm pondering the "portal" approach now; I've just been trying to minimize the number of related databases on general principles.

Cheers!

..Chris..

[danjacoby]

Have you considered doing a find for the owner? It's simple and effective.

[GibsonCRG]

Doing a "find" for the owner is what I'm after - however, I want to automate the process for the user as much as possible. Unfortunately, the owner list is dymanic, so it's not practical to have a seperate find script for each owner; conversely, the users are newbies, to some extent, and I'd prefer to avoid sending them into a "Find" mode window if I can avoid it.

..Chris..

[danjacoby]

Set the owner field up as a popup list, with the value list being the contents of the owner field (you can add a new owner to the list by creating a record and clicking twice in the owner field, then type in the "new" owner).

Now create a script that goes to Find mode, goes to the owner field and pauses -- the value list popup should be showing. All the user has to do is select the owner and hit the "continue" button in the status bar.

[BruceJ]

Ok - been there done that -

You can't use the header for data entry when you are in a List view.

One solution - create a global field(s) and then a portal. For the match criteria, create two calc fields that "tapper" the data with paragraph returns between the tappers, one for the global field and one for the field you're finding/filtering.

Create the portal with based on the relationship between the global's calc/tappered field and the other individual record's calc/tappered field. When the user enters info into the global field and then tabs out (or hits a "fake" find button that does nothing) - the portal will display the appropiate matches.

If you don't need to do the fancy filtering that requires a tapper, it's even easier - especially if you have a confined set of match criteria - you can just use drop down menus and skip the cumbersome calc fields.

Set up a layout with the global field(s) and the portal to resemble a "List View".

The great thing here is there's no need to go into FIND Mode. FIND Mode can cause problems because users will inadvertantly use Enter/Return to move between fields. No matter how much you try to idiot proff the solution - they'll always invent a better idiot. I've created the old fashioned "Find Layouts" and used FIND Mode - only to have the user enter info thinkning they are creating a new record - despite the special "Find Layout" that's supposed to clue in the most clueless that it's not for data entry!

[BruceJ]

Check out the example of this attached file.

Sample.zip

[GibsonCRG]

Good suggestion, Bruce - the combination of the portal, the global field, and the "fake" list view seems right on target. You really hit it right on the head in terms of why I was trying to avoid dropping "users" into the Find window - it just seems to confuse and/or annoy the users, depending on what they try to do in there.

Many thanks - it sounds like you have indeed "been there, done that!"

..Chris..

[BruceJ]

I'm glad it worked for you. 'Hope you were able to check out the example file too.

[GibsonCRG]

Absolutely! It was a fine example and very informative.

Thanks!

..Chris..