'sliding' portal?

[tomp]

Can a portal be made to 'slide' up like text fields?

For example, if I have a portal that displays 20 related records, and the vertical scroll bar is selected, but there are only 10 related records for the current conditions, can the bottom of the portal 'slide' up so that the empty portal rows don't show?

[mr_vodka]

If you mean like sliding in preview mode then yes.

[elipsett]

This seems to be what I need to know.
 

I am printing year-end pay reports for people we pay money to, and the information in the body is displayed using a portal. Each person receives one report for the prior year, listing payments for each month, and within each month by each individual job, and within each job by individual job items. The last item (job items within a given job) is displayed using a portal.

Everything else works fine, but the only way to display multiple job items for a given job is to set the portal to display a large number of records. Most people only have one job item per job, which means all those blank lines take up a lot of space.

 

Is there any way to dynamically set the number of portal lines displayed based on the number of records it will display?

So if there is only one job item, the portal will be only one line high. If there are 10 job items on that particular job, the portal window expands to hold ten lines.

 

Thanks.

[dansmith65]

Do all Jobs have at least one job item?  If so, look into using a sub-summary report instead.  From the sound of it, you would base the report layout on a job item table occurrence then get Job and People info from related tables in sub-summary parts.

[elipsett]

All jobs have at least one  job item.

A sample list might look like:

 

Joe Bloe

- January 2012

--Job No. 1

---Cleaning skyhook

---Installing new skyhook

--Job No. 2

---Loafing about

- March 2012

--Job No. 1

---Rinse and repeat

 

I can display all this just fine using reports and sub-summaries now. The trouble is getting that lowest level (---) to display all items, but no blanks. It does not have to be handled with portals but that seems to be the only approach that offers me a chance of getting what I want.

I don't completely understand your suggestion. This is a year-end report for contractors. We generate one report for each contractor, breaking down jobs and job descriptions within. Can you explain a bit more clearly? I am only beginning to get into reports and a lot of it hasn't gelled yet.

[dansmith65]

It would help if you read up on sub-summary reports, but I'll try to at least get you started...

 

Find all the Jobs you want on the report, then Go To Related Record[Job Items]. On the Job Items layout, add a sub-summary part that groups by JobId. Now if you sort the Job Items layout by JobId, it will group the Job Items by Job.

 

Using this method, you don't need a portal and it will not show any blank rows, but will always show all Job Items per Job, no matter how many there are.

[elipsett]

Thank you, Dan.
I got sidetracked by a customer who couldn't seem to locate his posterior with both hands, but should be able to get back to this shortly.

I understand what you're saying, and will try it soon. Probably tomorrow.

[elipsett]

I don't understand fully how it works, but it does indeed work.

 

Thank you very much for your time!

[dansmith65]

Your welcome, I'm glad you got it to work.

[ron G]

 

Find all the Jobs you want on the report, then Go To Related Record[Job Items]. On the Job Items layout, add a sub-summary part that groups by JobId. Now if you sort the Job Items layout by JobId, it will group the Job Items by Job.

 

Using this method, you don't need a portal and it will not show any blank rows, but will always show all Job Items per Job, no matter how many there are.

How does the GTRR figure in?  Why is it necessary (aside from the *fact* that it works)?

[Wim Decorte]

How does the GTRR figure in?  Why is it necessary (aside from the *fact* that it works)?

 

because the report is run from the child items context, which is the preferred method for reports.  You don't typically report from the parent's context and show the items in portals.  You do the report from the child context.

[ron G]

I guess I should be more clear. 

It seems the solution was to implement a Sub Summary report.  If so, where does the GTRR (script step?) figure in?

[mr_vodka]

You use it go the all the child records first. The report would be based on a TO of the child.

[ron G]

You use it go the all the child records first. The report would be based on a TO of the child.

Sorry to be so dense but I still don't see why GTRR is necessary.

 

Isn't a subsummary report based on the child lo enough?  I use a script to open the window, call the layout, do a Find, perform a sort and ba boom the sub summary is created.    In what sequence do you use gtrr?

 

Ron

[Wim Decorte]

Doing a find directly in the child TO, or doing a GTRR to the children after doing a find from the parents is the same thing.  Both produce the necessary found set in the child TO for the report.