8 Replies Latest reply on Feb 1, 2017 5:34 PM by markmeer

    Dynamically hide & resize portals in preview mode


      I'm encountering a couple of related formatting issues with regards to portals in preview mode, and hoping someone can assist...


      1. GOAL: Hide a portal if no entries, and replace with text


      • Created a text object ("No Items Found") and set "Hide object when" criteria to: Not(IsEmpty(PortalTable::PrimaryKey))
      • The portals have "Hide object when" criteria as IsEmpty(PortalTable::PrimaryKey), and "Remove blank space by: Sliding up based on all objects above"


      ISSUES (when in Preview Mode):

      1. When the portal above has no entries, it hides fine, but the portal immediately below does not slide up. (i.e. there is just a big space in place of the hidden portal).
      2. The "No Items Found" text, if placed over the portal, hides with the portal.  If placed above the portal, the portal does not slide up when the text is hidden.


      2. GOAL: Dynamically resize portal rows to fit contents

      TRIED: Shooting in the dark here...experimented with merge fields...but no luck


      1. Only number of rows specified in "Portal Setup" are shown, even if there are more entries. (in Browse this is fine due to scrolling, but in Preview-Mode, all rows need to be displayed.
      2. Some fields are single line of text, some multiple lines.  The portal rows in Preview Mode don't seem to scale to fit the contents.  Is it possible to get them to scale?


      I've attached a sample of the type of output formatting that I'm aiming for...

      Any help/advice/links greatly appreciated!

      Thanks in advance,


        • 1. Re: Dynamically hide & resize portals in preview mode

          You have experienced several of the reasons why portals are not good objects to use in a report.


          1.1 all layout objects located below a sliding object also need to be set to slide up. "Resize enclosing part" usually needs to be selected for all sliding objects as well.

          1.2 sounds like you are making the text object part of the portal. Drag the object out of the portal and make sure that moving the portal doesn't also move the layout text. You can then use the inspector's alignment tools to position the text object on top of the portal without it being part of the portal. This layout text also needs to be set to slide up/resize.

          2.1 This is a known limitation. All you can do is specify an extremely large number of rows and set it to slide/resize.

          2.2 This is also a known limitation for sliding layout objects. A workaround might be to use a calculation field that uses list or Execute SQL to combine the data in a single field or variable sized large with both sliding and paragraph formatting to put the data in a readable format.


          But ultimately, a list view layout based on the portals table is often a better way to set up such a layout.

          1 of 1 people found this helpful
          • 2. Re: Dynamically hide & resize portals in preview mode

            The best way to bypass problems like this is to go to the end of the links and create the report in that table.


            A <-> B <-> C <-> D


            If you make the report in D, then you can add breaks and fields from the tables to the left giving a result similar to your stacked portals.

            • 3. Re: Dynamically hide & resize portals in preview mode

              Thanks for the info.  It helps to know the limitations.

              That being said, I'm astounded that these are limitations (given the otherwise robust feature-set offered by Filemaker).


              Unfortunately though, I don't think a list view will suffice.


              The actual situation is this:

              We've got Forms that include portals of varied size, and we'd like to be able to print the forms (in a nicely formatted way), including the contained portal rows.


              For example, a "Customer Complaint" form has a portal to a "Notes" table, allowing users to add rows each time they interact with the customer.  These notes may be short, one-line text, or large paragraphs of text.

              The printed forms must include all the "Notes" entries (i.e. display all rows of the portal).


              I appreciate the workaround you've outlined in 2.1.  I'll try it on a new dedicated print layout. But unfortunately this is inadequate as a long-term solution, as it will always be unknown a) how many rows there are in the portal; and b) how much text there is in each row.


              Do you know if there's a way to log a feature request to Filemaker developers to address this limitation?

              • 4. Re: Dynamically hide & resize portals in preview mode

                I'm now musing as to whether it's possible to resize the field in a script to fit the contents (e.g. prior to being printed)?


                For example, given the following parameters:

                1. Field width
                2. Font size
                3. Number of characters

                could a script be developed to set the field's height so that all the text is encompassed/visible?

                • 5. Re: Dynamically hide & resize portals in preview mode
                  Do you know if there's a way to log a feature request to Filemaker developers to address this limitation?

                  Select "Home" at the top of your screen and then click the link for Product Ideas. Do some searches before posting your idea as someone else may have already posted it. If they have, you can open their post and vote in favor of it as well as adding your comments in support of it.


                  If I understand you correctly, you can't use a list view layout because you have more than one portal and each is to a different table. Otherwise, a list view is definitely possible to use here.


                  In cases where there is more than one related table, I will base the layout on the table occurrence of the portal that is likely to be the hardest format correctly as a portal, then use portals for the others. That solves the issue for the most troublesome portal at least.


                  Other options for reporting:

                  Set up a "report table" into which you import the data from all of your portal based table at the time you need your report. This tends to be a monster table with lots of fields in order to accommodate the different fields of the different related tables. You then set up a list view layout based on this report table where you sort to group the records from the different original tables. You also typically end up with layered fields and field labels with lots of "hide" expressions to customize the different rows of data to work for the different sub lists that make up your report. If the data is fairly simple in each original table, this is manageable, if not, this can be a major nightmare to set up and maintain.


                  You can also use ExecuteSQL and List to generate a single block of text listing the contents of a portal or event more than one portal in the case of ExecuteSQL. This gives you options where you use tabs to separate columns of text and set use the tab stops and paragraph formatting in the inspector to control column widths and indents for the data returned by one of these functions. This can sometimes solve the problem you identified earlier when you tried to get a portal to slide up and found that all rows have to be the same height as the text will "flow" smoothly together in that block. You can set this single field to slide up and resize with the same "can shrink, can't grow" limitation as for other sliding objects.


                  You can also set up a script or calculation to compare the number of portal rows to the maximum allowed portal height and at least show a warning message that the portal needs to be made larger.

                  1 of 1 people found this helpful
                  • 6. Re: Dynamically hide & resize portals in preview mode

                    Using a Report view, there is no limit on the number of items that will display other than your find criteria.


                    Try this:


                    Use the related table as the source of the records. Create a header that shows related info from the parent file then the portal records (this table) will show up with the parent. This is a standard trick for printing invoices.


                    The sub-summary can display text from the parent Table.

                    The body lines show text from the portal table plus other tables.

                    1 of 1 people found this helpful
                    • 7. Re: Dynamically hide & resize portals in preview mode

                      You can create the layout with the body part sized for several sheets of paper and then have the objects slide up and reduce their size. Thus a body part 3 pages long might only print one line on the report. Drag the bottom line of the body part downward so it resizes as large as you like within its limits. Place your fields on it and resize them by dragging boundaries.


                      Also note that you can assign scrolling to a field using the Inspector...

                      • 8. Re: Dynamically hide & resize portals in preview mode

                        Thanks for the suggestion.


                        It works well in the case that there is only one associated table, as in your example of Invoices (parent), and Invoice_Items (portal).


                        However, what about the case where there are multiple associated portals?

                        For example, an Employees (parent) table might have the following associated tables: Training_Sessions, Employee_Incidents, and Supervisor_Notes, all of which have variable number of entries, and variable field text-lengths.  In a printed employee report, you'd like to be able to print all this data in a tidy fashion....


                        I really like the idea of a portal layout part (much like a sub-summary) described here.  But until such a feature (or other solution) is available, I guess I'm resigned to the 3-page sliding fields that you suggested.