12 Replies Latest reply on Apr 12, 2010 12:09 PM by philmodjunk

    shrinkable 'portal'?



      shrinkable 'portal'?


      I have a report that includes a portal of 13 rows.  Sometimes the data uses 2 rows.  Sometimes 13.  Most of the time something between 2 and 13. 


      Question: "Is there a way to shrink the portal to just the number of rows with data?"



        • 1. Re: shrinkable 'portal'?
             No, but you can - and should - produce the report from the child table.
          • 2. Re: shrinkable 'portal'?

            This is a long standing limitation of portals. They make a pretty good tool for entering data, but not for printing in a report. You may be able to create a report that works for you if you create a List view report layout based on your portal records. You can then use the same relationship as your portal to put fields from your main table in header and sub header parts of your report.


            Example: Main Table contains States (california, Nevada, ....) with other fields recording data about each state. Define a Cities table with State and City fields. Create a relationship that Matches State in the Main table to State in the Cities Table. Your portal's table shows cities. On the California record you see "Los Angelos, Sacramento, Stockton...." On the Nevada record you see "Las Vegas, Reno...."


            Define your portal's table (Cities) as the table for your report layout. Put the City field in the body of your report. Put information from the Main table in subsummary parts and sort your records by "State". You then get:


            California (and any other data about California that you need from the Main table)

              Los Angelos




            Nevada (and any other data about Nevada that you need from the Main table.)

              Las Vegas



            This report may not have the "look" that you had in mind but it will grow and shrink each section of data entered in your portals as you asked.

            • 3. Re: shrinkable 'portal'?

              IF your report is viewed in preview mode the sliding up baseed on all above option is on as well as also reduce the size of the enclosing part option is on.


              In preview the portal will shrink to the size the amout of records

              • 4. Re: shrinkable 'portal'?
                   Right. I should have mentioned that: portals do shrink when set to slide up. Still, printing from the child table is the preferred method.
                • 5. Re: shrinkable 'portal'?

                  Yes the portal shrinks but it leaves a space and does not appear to 'slide up' the records below.  I will fool around with it and see if I can get that to work.



                  • 6. Re: shrinkable 'portal'?

                    Check all your settings. I'm using FMP 10adv and it does shrink the body part of my layout. So this can be made to work. As always, this affect is only visible in preview mode or on the printed page.


                    Comment, if you're going to keep saying "Printing from the child table is the preferred method", you should share your reasons.


                    From an historical perspective, Printing a sliding portal did not work and so most users avoided them. Printing from the child table was the easy and effective way to do that. Now that I can get them to shrink, I can choose the look and function that best works for my particular design.


                    I see two significant issues when using a report in printing:


                    1. You won't see all your portal rows if the number of related records is more than the maximum size of your portal. (Unlike an MS Access subreport, you can't make it grow)
                    2. Your layout may look very different depending on whether you are in Browse or Preview Mode.


                    Both problems are avoided by printing from the child table.

                    • 7. Re: shrinkable 'portal'?

                      PhilModJunk wrote:

                      Comment, if you're going to keep saying "Printing from the child table is the preferred method", you should share your reasons.

                      Fair enough.

                      Portals shrink only to reduce the number of rows - but the height of each row remains constant, regardless of the row contents.

                      Portal do not always handle page breaks well.

                      But the most important reason, IMHO, is that a portal ALWAYS shows ALL related records. When reporting from the child table, you can perform a find to tailor the report to fit the requirements; for example a report of sales by product can be easily restricted by date range, or by geographical area, etc. - all using the same layout. To do the same thing with a portal, you'd need to predict all possible future requirements and prepare a filtered relationship and a matching layout for each.


                      And I haven't mentioned sorting… 

                      • 8. Re: shrinkable 'portal'?



                        That's exactly what I was asking for. All good points to keep in mind.

                        • 9. Re: shrinkable 'portal'?

                          Hi Phil, I implemented your suggestion in a situation similar to the one described in the initial posting, but I would like to take this a step further: how can I limit the output to the table?  I would like the script associated with the 'List View' layout to only show specific records.  I tried editting the script itself, but I can't seem to get it to work.  Can you offer some scripting advice for this situation?





                          PS. I'm now working in FMPA 11

                          • 10. Re: shrinkable 'portal'?

                            To "only show specific records" you need to somehow control which records make up the found set at the time you print and/or preview the report.


                            Usually, this means performing a find, though a Go To Related Records step can also be used in some situations.


                            Just keep in mind that your summary fields only use data from the found set to compute their results.


                            Can you describe what you want here in more detail?

                            • 11. Re: shrinkable 'portal'?

                              Phil, I what I would like to do is to run a script that searchs for records that have the same conditions as the current record.  In this situation, I would like a script to search for records that have the same "StorageID" and "IncludeY_N" values.  I thought I could write the script to include 'Set values as' and then do a find, but I know that is backwards.  What do you think?

                              • 12. Re: shrinkable 'portal'?

                                I don't see anything backwards about that. I use this method fairly frequently:


                                Set Variable [$ID ; YourTable::StorageID]

                                Set Variable [$Include ; YourTable::IncludeY_N ]

                                Enter find mode[]

                                Set Field [YourTable::StorageID ; $ID]

                                Set Field [YourTable::IncludeY_N ; $Include]

                                Set Error Capture [on]

                                Perform FInd[]


                                With a slight change in the details, you can also use this approach to use the data in the current record of table 1 to search for matching data in  table 2.