Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Portal sorting and self-join relationship

Featured Replies

I found some great methods of sorting portal on the blog fitchandfitch.com.

( http://www.fitchandfitch.com/2011/05/filemaker-portal-sorting-redux/ )

I want to modify the file „PortalSort Petrowsky.zip" (created by Matt Petrowsky).

In this file we have a typical situation. There are two tables and relationships between them.

I wanted to have only one table with the relationship between self-join.

My unsuccessful modification in the attachment. Please help me.

PortalSorting Petrowsky mod.zip

I notice that you made a new layout and renamed the portal as "portal.y" but your sort script still calls for "portal.x" -- however, making this change did not correct the problem.

Matt does beautiful work but honestly I find his methodology somewhat hard to work with. I don't think all those custom functions make it necessarily more efficient to achieve the desired result. They certainly don't make it easier for me to debug your problem.

I notice that you made a new layout and renamed the portal as "portal.y" but your sort script still calls for "portal.x" -- however, making this change did not correct the problem.

Matt does beautiful work but honestly I find his methodology somewhat hard to work with. I don't think all those custom functions make it necessarily more efficient to achieve the desired result. They certainly don't make it easier for me to debug your problem.

I would agree with that FItch.. Too much Custom Functions make it hard to read / debug and well, UNDERSTAND what is going on besides the person who wrote it.

  • Author

I am a little worried when I wrote first post. I know that my question was a bit too general.

(...) however, making this change did not correct the problem.

My attempts darken original code. Code becomes useless. I rollback changes.

Matt does beautiful work but honestly I find his methodology somewhat hard to work with.

Yes it's true. They are very nice.

I would agree with that FItch.. Too much Custom Functions make it hard to read / debug and well, UNDERSTAND what is going on besides the person who wrote it.

And I agree with both of you.

What I found was that your portal sort calc field needed to have the context changed to "Child_Self" because you are passing field names as Child_Self::name and such. That got the calc to work properly.

Also you have your portal named "portal.y". The script sets a variable to "Portal.x"

I changed both those and thought it would fix the problem but still no go. So there's still something else..

Well, it was quite a challenge unravelling everything and finding the problems. Here's what I did;

Changed the script parameters to Child::field rather than Child_Self::field ( rather than changing the evaluation context mentioned above to fix the calc )

Changed the portal object name and all references to it back to "portal.x" ( The name was referenced in a few places, so i just went back to .x )

Fixed the sort script steps to sort by "Child::Field" instead of "Child_Self::Field" ( You're sorting on a layout based on the Child TO, not the Child_Self TO )

Changed the If statements from PortalSortDirection ( Child_Self::Field ; $portalObject ) = "Ascending" to PortalSortDirection ( Child::Field ; $portalObject ) = "Ascending"

I think that was it. I changed things arround a few times to get all the contexts right so I may have forgotten something, but i'm pretty sure that's it

I use a very different calculated portal sort technique and when comparing this to the one I use this sure seems to be way more complicated than I would want to get into. But good luck :).

PortalSorting Petrowsky mod Fix.zip

Here's the technique I use, pieced together a while back from various sources..

One of the things I don't particularly like about the global list techniques for establishing the sort order is that it has to go to related record to create the list. If the portal has a scroll bar and it is scrolled, it will lose it's position and the scroll will pop back up to the top.. I'm not sure if that holds true with the self joing examples we're dealing with here but with a non self joing parent child type portal it would have to leave the layout and come back resetting the portal scroll to top..

PortalSort RC.zip

  • Author

Thank you very much for your help. Your explanation helped me understand what I was doing wrong.

Your sorting method is also very cool (without custom functions)

Thank you again for help.

Here is yet another approach to portal sorting that I think I posted here some time ago.

The method is to use a single visible display portal and in a hidden tab, use multiple named portals that are sorted in different directions and by different fields.

Then a collector script gets the contents of the appropriate named portal depending on which sort order was selected, and collects the ID list for that portal.

It works OK for modest record sets; and could use some further refinements.

There are similar techniques (multiple portals with hard wired sort orders) but most of those techniques require you to switch the view to a tab which contains a copy of the portal that is based on the desired sort order.

The advantage of this technique is that you use only a single display portal, so you only have one place to edit the appearance of the portal. By appearance I mean which fields are displayed, field size, etc.

TabPortalSortBFR.fp7.zip

That's a really interesting idea, Bruce. Thanks!

  • 1 month later...

First of all, be aware that GetNthRecord gets perceptibly slow with a few hundred records, and painfully slow with many thousands of records. YMMV, but I wouldn't recommend that as a list collection method for large found sets. I don't think portals are appropriate for large data sets in general. Regardless of your data set size, have you considered just using a list?

I've pondered your file a little, and it looks like you're passing in the related field name as a script parameter, but I think you'd want to pass in the parent field (i.e., data::author instead of foundset::author). But there's more to it than that, and I don't have the time or caffeine to pursue it. Good luck.

  • Author

I have a little success. I used Ron technique. Tomorrow I will write more details. ...

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Account

Navigation

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.