Trying to calculate the number of portal rows displaying in a filtered portal.

Note that this is for a script calculation, not display (i.e. displaying a summary count in it's own one-line portal is not my answer in this case)

The reason I am trying to do this is: layout has an instant search field for a portal of related records (uses filtering to search), and when a search returns only one record, I want to automatically switch to an editing layout.

The many wise ones here may well have a better approach!

Thank you!

Juz

By "instant search," you mean that the filter is a global? Are you using filtered portals bcs the field that you're filtering by is unstored? If that is the case (and so you cannot build the portal using a relationship), then how about an off-screen Find and if Get (FoundCount)=1, go to editing layout?

More details of you exact setup would be helpful.

Wow, you guys are speedy.

You're on the right track. I have a global field on a dashboard layout, which is used in portal filtering logic to display matching records in a portal on same layout.

So I am wanting to count the records DISPLAYING (not just related), in order to:

(1) detect when the filter returns only one match, and go to it.

(2) detect when the filter returns no match, and put up a "no records found" message (blank portals are confusing

Makes sense?

Note that this is for a script calculation, not display (i.e. displaying a summary count in it's own one-line portal is not my answer in this case)

This is a problem, because portal filtering occurs at the layout level - so it's difficult to get at the results from the data level. If you cannot use relationship filtering instead, consider placing the summary field in it's own one-line portal anyway (or inside the existing portal), give it an object name, and use GetLayoutObjectAttribute() to get the displayed value.

And the idea of an off-screen Find doesn't work because...?

Please confirm that you can't filter by relationship.

The reason a filter was my choice rather than a straight relationship, is because there are a few different filtering criteria at work, and not all are from the same table.

I will describe the solution here, see if you think I made the right choice?

DASHBOARD table holds the filter and UI criteria base don current user.

JOBS table holds a list jobs in various filterable statuses

TASKS table holds all tasks assigned to a job.

The dashboard view is actually looking through TASKS then to JOBS, and displaying JOBS in the portal.

[dashboard] --A--> [tasks] --B--> [jobs]

That's because the dashboard shows you only jobs in which the USER has a task.

So relationship A uses USER and STATUS (open or closed tasks) to the TASKS table, then returns the related jobs using relationship B (simple ID).

The portal then uses filtering to limit the JOBS by other job-level criteria, (such as Overdue or Held jobs).

I couldn't work out how to do that "criteria across two tables" piece with just a relationship?

Did I miss something? (quite likely!)

(and yes, I can go off, perform find same as filter, and return foundcount, and store that somewhere to use for the calculation, but seemed like it may be a bit slow/clunky)

Thanks again for the assistance.

I couldn't work out how to do that "criteria across two tables" piece with just a relationship?

By placing the job-level criteria (global) fields in the Tasks table. They can still be shown on the dashboard layout.

You said originally that you're doing this calculation as part of a script. If so, this may be a solution for you:

Go to Object[ "your portal" ] // your portal needs an object name for this to work

Loop

. Set Variable[ $rows ; Get(ActivePortalRowNumber) ]

. Go to Portal Row [ Next ; Exit after last]

End Loop

The variable $rows now contains the number of portal rows.

Could you not cut to the chase:

Go to Portal Row [ Last ]

Set Variable[ $rows ; Get( ActivePortalRowNumber ) ]

If the portal is furthest to the back in layout's stack order (or the only portal on the layout), then that's all that would be required.

---

I still think the method suggested in post #4 is simpler - and it will work for other types of summaries as well.

Edited March 30, 201114 yr by comment

Could you not cut to the chase:

Go to Portal Row [ Last ]

Oh... of course. I pulled that out of part of a script I was using for something else. Good catch.

And yes, GetLayoutObjectAttribute on the summary field is ingenious... but not simpler IMO.

That solves the problem! Thanks everyone. I was under the mistaken impression that couldn't detect "active" because their were no browsable fields in the portal, but "activerow" has nothing to do with that of course!

I will have to do something about removing the focus on the last row afterwards, but thats trivial.

As a response to the post re: moving the Filter.Globals to the Task table, this is my first attempt at a Data Separation Model solution, so I have tried to avoid putting any UI related variables into the data storage tables if I can help it. May not hold up till the end of my solution, but this is a learning experience for me and my previously pretty flat solution architectures.

Thanks again folks!