Filter based on layout... no Search

[NickFaraday]

Is there any way I can filter a table based on the layout?

I want to do this without doing a search.

So if I have a table of lists and each list has a list type, how can I show just one type of list on a given layout.

[Brian C]

you can create an unstored calculation field for the table that uses get(layoutname) in some way. You could then combine this with another key to create your relationship to filter the portal.

[NickFaraday]

ya, I'm not looking to filter a portal, rather the table the layout is based on.

Basically I want to replicate the functionality of a "Find" without having to preform the find. If I have to lock it to a layout thats fine.

So if I were to go to my list layout and preform a find on the list with a list type of say "Archive" I will get a subset of the list table that only has the type "Archive". I want only that subset attached to a layout called Archive, that is filtered automatically. AKA you don't have to preform the find manually in the layout.

You can do this with a script, but there is no way to trigger it upon entering a layout. Or maybe that is another question. Is there a way to trigger a script upon opening a layout?

[bcooney]

Have a button attached to a script that goes to the Archive layout and does a find for type = "Archive". Don't use the layout popup above the rolodex icon in the status panel, use buttons to navigate to different layouts.

However, if your user is in a list view in which you've performed a find for them using a navigate button, you must maintain that sub-set of found records. That is, if they can click a find button on this list view, your script that performs the find will need to constrain their found set to type = "Archive".

That is why filtered portals are nice. There is no "escaping" the found set.

[NickFaraday]

exactly what I am trying to avoid.

[bcooney]

Huh? What are you trying to avoid, users "escaping the found set?" If so, you need to script everything that they do if you are going to use a list view in order to guarantee that this list view only shows the proper found set and not a portal which is a "hard-coded" found set.

[David Jondreau]

How are you "opening the layout"? If you're talking about choosing one from the drop down list, I don't think it's going to happen. You could set up a Custom Menu that includes a list of layouts and when one is chosen, it will run your Find script.

[NickFaraday]

Not trying to avoid "escaping the found set" but rather recreating a navigation system. This db is used by a lot of people cycling in and out of the office on a freelance basis and new interfaces no matter how good always come with some kind of learning curve.

Everyone knows the FM interface, so I don't want to circumvent it.

[NickFaraday]

This might work... I'll give it a try. I can hide all the menu's from the "Layout" box and create a "Layout" Drop down menu.

Don't suppose you can overload the "find" shortcut on a layout in FM?

[David Jondreau]

You mean "override"? Sure you can do that too. You just create a script and attach it to the shortcut key. Or delete it entirely. It's still pretty unclear what you're trying to do.

Are you trying to get users to have one found set whenever they view a certain layout? My original suggestion was for this problem.

Or are you trying to allow users to use the native "Find" mode of Filemaker to find records, but restrict that found set based on the layout they're "Finding" from?

If the latter, you could attach script to the drop down Find selection that Enters Find Mode then Set Fields the type based on the layout. You'll also need to modify the New Request shortcut and delete the Show All Records and probably the Extend Found Set as well. The Omit button could present little issues (user makes an additional find request, omits, but neglects to put anything in, no records found).