Jump to content

  •  

Photo

Display Find Results in a Portal

perform find portal

  • Please log in to reply
9 replies to this topic

#1 MariaAux  apprentice

MariaAux
  • Members
  • 142 posts
  • FM Application:11 Advance
  • Platform:Windows 7
  • Skill Level:Novice
  • Time Online: 5d 20h 24m 3s

Posted 27 January 2012 - 02:19 AM

Hi There,

I did a google search to learn more about displaying find results in a portal i.e. perform a find and only those resluts should be displayed within a portal and I found a couple of ideas. One was the concept of multi-key fields but I noticed the video was done with an older version of Filemaker. With FM 11, we have the ability to do a filter within a portal based on a calcualtion and I wonder whether there isn't an easier way now with FM11 to use this portal filter functionality to produce a portal with only the find results?

Is Multi-keys still the best way or is there a better way with Portal filters?

Thanks so much for your advice and time.
Maria
  • 0

#2 Fitch  Imaginary friend

Fitch
  • Moderators
  • 4,013 posts
  • LocationPortland, Oregon
  • FM Application:13 Advance
  • FMGo:iPhone / iPod Touch, iPad
  • Platform:Cross Platform
  • Skill Level:Expert
  • Certification:7, 8, 9, 10, 12
  • Membership:TechNet
  • Time Online: 16d 5h 21s

Posted 27 January 2012 - 03:45 PM

A portal filter doesn't have any "awareness" of the found set, so it can't really help you there. A multi-key field seems like the way to do it.
  • 0
Tom Fitch :: Portland, Oregon :: Fitch & Fitch: FileMaker consulting

#3 dansmith65  veteran

dansmith65
  • Members
  • 856 posts
  • LocationB.C. Canada
  • Certification:8, 11, 12, 13
  • Membership:TechNet
  • Time Online: 14d 22h 31m 57s

Posted 27 January 2012 - 07:58 PM

Why do you want to display find results in a portal? What's wrong with displaying them in list view?
  • 0

#4 LaRetta   Lifelong FM Student

LaRetta
  • Members
  • 9,645 posts
  • LocationOregon
  • FM Application:13 Advance
  • Platform:Mac OS X Mavericks
  • Time Online: 204d 10h 40m 56s

Posted 28 January 2012 - 08:24 AM

Is Multi-keys still the best way or is there a better way with Portal filters?


Hi Maria,

It is usually best to use relational filter instead of portal filter because portal filters have to evaluate all records before constraiining the results. This is great stress on your system when you have a lot of records. And since either way, you would need to collect the IDs of the record-set, it is best to use multi-line (global or calculation) in new relationship to the portal. Check out this thread for gathering IDs from a found set: http://fmforums.com/...__fromsearch__1

Hi Dan,

Sometimes it helps (when viewing a form layout of multiple records) to see a portal on the side of those same records. It acts as an visual index and can allow click-jumping to specific records within the found set. :)
  • 0
Each assumption is an educated guess, a likely condition or event, presumed known and true in the absence of absolute certainty.

#5 BruceR  consultant

BruceR
  • Members
  • 3,267 posts
  • LocationRedmond WA
  • FM Application:13 Advance
  • Platform:Mac OS X Mountain Lion
  • Skill Level:Expert
  • Certification:9, 11, 12
  • Membership:TechNet
  • Time Online: 27d 11h 26m 31s

Posted 28 January 2012 - 03:37 PM

I would qualify that statement about portal filters; you can do both.

If the potential set of unfiltered records is large, then the relationship should be designed as the first filter. Portal filtering can then be used as a secondary filter.

The portal filter calculation will operate on the entire record set of values presented by the relationship. The portal filter calc operates on these records strictly in creation order, independent of how the relationship definition or portal definition sorts them.
  • 0

#6 LaRetta   Lifelong FM Student

LaRetta
  • Members
  • 9,645 posts
  • LocationOregon
  • FM Application:13 Advance
  • Platform:Mac OS X Mavericks
  • Time Online: 204d 10h 40m 56s

Posted 28 January 2012 - 04:08 PM

Thanks, Bruce. Yes, many times we further portal-filter a relationally filtered relationship. Whew! That was a bite-full!

The portal filter calc operates on these records strictly in creation order, independent of how the relationship definition or portal definition sorts them.

I did not know this! I thought this was interesting but wait ... it would not really matter since all of the related records must be walked through by the filter anyway, would it? Where might knowing that sorts are ignored by portal filters, be important? After all, we are talking about filtering and not calculating, right? Thanks for stepping in.
  • 0
Each assumption is an educated guess, a likely condition or event, presumed known and true in the absence of absolute certainty.

#7 BruceR  consultant

BruceR
  • Members
  • 3,267 posts
  • LocationRedmond WA
  • FM Application:13 Advance
  • Platform:Mac OS X Mountain Lion
  • Skill Level:Expert
  • Certification:9, 11, 12
  • Membership:TechNet
  • Time Online: 27d 11h 26m 31s

Posted 28 January 2012 - 06:24 PM

Depends on what you are trying to do with the filter calc.

For instance, assume a sorted relationship to a people table, sorted by last name; where the relation uses a global field to match on City.
Set the filter field to "Seattle". Say there are 2000 Seattle people; 75 whose last names begin with "A".

Have a script that sets variable $$names to empty and then does a refresh.
The portal filter uses this calc:
Let( $$names = List( $$names; People::LastName); Left( People::LastName; 1) = "A")

What will the portal show?
(Only the 75 Seattle people whose last names start with "A"; sorted by last name).

What will $$names contain?
(The list of all 2000 Seattle last names; unsorted.)
  • 0

#8 BruceR  consultant

BruceR
  • Members
  • 3,267 posts
  • LocationRedmond WA
  • FM Application:13 Advance
  • Platform:Mac OS X Mountain Lion
  • Skill Level:Expert
  • Certification:9, 11, 12
  • Membership:TechNet
  • Time Online: 27d 11h 26m 31s

Posted 28 January 2012 - 06:37 PM

Or consider this variation for the filter calc:
case( Left( People::LastName; 1) = "A";
Let( $$names = List( $$names; People::LastName); 1)
)
Now $$names contains the list of Seattle last names beginning with "A"; but it is unsorted.
If instead you collected the record ID values into the variable, you might have assumed it represented a sorted list. But it won't.
  • 0

#9 MariaAux  apprentice

MariaAux
  • Members
  • 142 posts
  • FM Application:11 Advance
  • Platform:Windows 7
  • Skill Level:Novice
  • Time Online: 5d 20h 24m 3s

Posted 01 February 2012 - 07:26 AM

Thank you all so much for your invlauable advice. Got me where I wanted to be! Thanks a million
  • 0

#10 dansmith65  veteran

dansmith65
  • Members
  • 856 posts
  • LocationB.C. Canada
  • Certification:8, 11, 12, 13
  • Membership:TechNet
  • Time Online: 14d 22h 31m 57s

Posted 01 February 2012 - 12:11 PM

Hi Dan, Sometimes it helps (when viewing a form layout of multiple records) to see a portal on the side of those same records. It acts as an visual index and can allow click-jumping to specific records within the found set. :)

I'd never heard of this interface technique before; sounds interesting. I couldn't see any practial use of displaying find results in a portal, so thanks for pointing this out.

Now you got my gears turning though... This could possibly be an alternative to using a filtered portal. It would take a lot more work on the developers end, but it would allow for greater flexability for the users 'filters'.

The portal filter calculation will operate on the entire record set of values presented by the relationship. The portal filter calc operates on these records strictly in creation order, independent of how the relationship definition or portal definition sorts them.

Interesting detail. like LaRetta, I failed to see the relevance of this at first, but your examples were interesting. I can see how this aspect of the portal filter could possibly be levereged for some cool custom feature.
  • 0





FMForum Advertisers