Grab total of filtered portals

[Daniel Shanahan]

Is there a way to grab the numerical value of a filtered portal? I have a filtered portal in FMP 11; using the portal filter feature rather than filtering via a relationship.

I can view the number of items in the filtered portal via another portal with one row (see http://fmforums.com/...ed-portal-rows/). Now, I would like to grab that value and put it into a variable.

Purpose:

I am "listening" for up/down arrows in order to navigate up and down in the portal (using OnLayoutKeystroke). The script works fine and I can easily navigate up and down in the portal via the arrows. I have a condition that states if I am on portal row 1 then disregard the up arrow keystroke. I need the same kind of logic when I press the down key. I store the portal row in a global variable. As it is now the down key will continue to increase $$portalRow ad infinitum. I'd like to be able to say something like

If $$portalRow = $totalPortalRow then exit.

Again, viewing the total number in the filtered portal is not the problem. That works fine. I would like to grab that value and put it into a variable.

Thanks.

Edited September 17, 2011 by Daniel Shanahan

[LaRetta]

If you want the total number of records being displayed in a filtered portal (vs.11) then you can easily get it from within any portal row if the table the portal is based upon has a summary field Total Count of any non-empty field such as ID, maybe called sKountKids ;-) . Then in script, while in portal row, just reference this child summary field. The count (in fact all summaries) will be filtered this way as long as you go to the portal first.

ADDED: So it would be: Set Variable [ $totalRows ; Child::sKountKids ]

[LaRetta]

I take that back. If it is the only portal on the layout then it seems to *see* the filter and produce the correct results. If I place an unfiltered portal (based only upon ID) then it STILL sees the first portal summary!! So it seems to *see* the first in stacking order, I think confirmed.

I've used a global filtered portal whose only purpose is to provide filtered summaries for scripts but I never noticed that it wasn't necessary to go to a row unless the layout contains two portals to same table occurrence.

Oh, never mind ... lol ... I was running a script in test file and the script had first step of Go To Portal Row ... lol ... forget this latest miracle discovery ... what I said in original responds holds. :laugh:

[Daniel Shanahan]

Thanks, LaRetta. That works great!

I also learned of another method from Dave Ramsey at the Central Ohio FileMaker Users Group (COFMUG):

Give the merge variable a name and then use the function GetLayoutObjectAttribute. Dave tells me that he learned this method from John Sindelar who learned it from someone else, so thanks to all those involved. Attached is a file showing both methods.

Thanks again for your reply, LaRetta.

portalFilterGrabTotal.fp7.zip

[comment]

Give the merge variable a name and then use the function GetLayoutObjectAttribute.

This method has been mentioned here several times, e.g.:

http://fmforums.com/...639#entry339639

http://fmforums.com/...117#entry363117

However, if you are in the context of a script anyway, then placing the summary field in a filtered portal (or even doing GTRR from a filtered portal) is cheaper in terms of required resources.

[Echo33029]

Daniel, actually you can probably make your life a little easier and ditch the variable totally. FM will ignore the GoToPortal Row(Next/Previous) command if you are already at the first or last protal row. I use the following script to allow the use of the arrow keys to navigate on a layout, You can modify it to suit your own requirements. You must give the portal an object name.

UpDownKeys.pdf

[LaRetta]

Hi Daniel,

Thank you for sharing the file! I had forgotten about using GetLayoutObjectAttribute ... more than a few times, it seems. :crazy2:

[imoree]

Can someone Please xplain how / why this works. Seems these techniques only work if you

put the field over a portal (child::related) table. Why does this work?

Or am i just being silly?

thanx..

-i

[Daniel Shanahan]

Can someone Please xplain how / why this works. Seems these techniques only work if you

put the field over a portal (child::related) table. Why does this work?

imoree, can you clarify what part is confusing you? There are a couple of different elements:

1. Filtered portals vs. multi-value relationship

2. Displaying portal aggregates from filtered portals

3. Grabbing the value of an aggregate of a filtered portal in order to use it in a script