1 2 Previous Next 25 Replies Latest reply on Apr 25, 2017 10:18 AM by BruceRobertson

    Multiple output lists in expanding body

    tleitzke

      In my bid app, I am on the final portion of adding in the final output sheet. The sheet needs a header and footer (when in print, there will be only a header on the first page, and only a footer on the final page, so only 1 header and footer total.)

       

      The body, I need to expand to the content inside- which I need to expand too. For example, I need to list out all the equipment, accessories, extra expenses, warranties, rebates, and extra expenses (all of which WILL contain 2 more items; which is currently seen as portals in the main bid form), and should they continue onto a second page (print wise), I need the body to expand with the content. I tried looking into auto-resize, but the filemaker help pages said they only resize when the window resizes.I don't want the contents themselves to resize (changing font to smaller so that it all fits).

       

      It would be nice and easy if there was a way to resize a portal to show all contents, and anchor a "total" field (if need be), and then add a another portal after that (doing the same resize) but anchored to the first portal so they do no overlap.

       

      "equipment, accessories, extra expenses, warranties, rebates, and extra expenses " are all on separate tables from the main table the layout must be based on (bid).

        • 1. Re: Auto-Resize to Content (instead of window)
          Jason Wood

          I think you're looking for the SLIDING options.

           

          Removing blank spaces in printouts

           

          When you apply these sliding options, the effect can only be seen in Preview mode.

           

          But it sounds like you're printing a portal and generally you should not be printing portals. The printing layout should be driven from the child table.

          • 2. Re: Auto-Resize to Content (instead of window)
            keywords

            Re: "It would be nice and easy if there was a way to resize a portal to show all contents"

            You cannot expand a portal dynamically, but you can reduce it using the sliding options. Nevertheless, if your purpose here is reporting it is far better practice to build a specific, separate report layout based directly on the portal TO. Portals are intended for screen display, not reporting.

            • 3. Re: Auto-Resize to Content (instead of window)
              tleitzke

              So sliders are a thing to use, and portals are a giant "no no".

               

              I need everything to fit in a small 1-2 paper page (of course more if need-be), so I do not want to use an entire layout per page. The final output of things will be fairly small for each would-be portal/table, consisting of morely text than visuals (like these replies).

               

               

               

              [HEADER INFORMATION]

              Equipment:

                 piece 1

                 Piece 2

                 Total: $XXX

              Accessories:

                 Piece 1

                 Total: $XXX

              Rebates:

                 Rebate 1, $XXX

              ....

              [FOOTER INFORMATION]

               

               

              Is how the final output should be (being laid out. So not just a single list, but several- one after eachother)

              • 4. Re: Auto-Resize to Content (instead of window)
                tleitzke

                (As kind of a bump)

                 

                This is an image of the header and footer of the final output I need/made( This is a current layout in Filemaker). The red box (Body/Content) is where I need the tables of Equipment, Accessories, Rebates.... to show up- and to grow. However, I do not know how to make tables inside of the layout, without using portals-> which have been said already to not be good when printing.

                 

                Capture.PNG

                • 5. Re: Auto-Resize to Content (instead of window)
                  Jason Wood

                  Is Equipment, Accessories, and Rebates all in the same line items table?

                   

                  If so, great! Change your layout so the base table is the child table. Then double click all your existing fields in the header and footer and reconnect them to the parent table (if needed).

                   

                  Now you can shrink the body part to be only large enough for 1 line. Add in whatever fields you need for each line. Looks like you probably do not need to use the Sliding features - unless some lines will be taller than others.

                   

                  To get subtotals for Equipment, Accessories, and Rebates, add a Sub-Summary part and set the "when sorted by" to a field that indicates that line type.

                   

                  Your printing script will do these basic steps:

                   

                  If [ Count ( lineitems::id ) = 0 ]

                    Message: Nothing to print!

                  End if

                  Go to related record from lineitems (current record only)

                  Sort records by line type (Equipment, accessories, rebates)

                  Print (and be sure to select "records currently being browsed" and not "current record")

                  Go to original layout.

                  • 6. Re: Multiple output lists in expanding body
                    tleitzke

                    " "equipment, accessories, extra expenses, warranties, rebates, and extra expenses " are all on separate tables from the main table the layout must be based on (bid)."

                     

                    As I said in the first portion, no. They are all on separate tables as they are not "Line Items" and have many unique variables specific to that one portion (And too much to manage on a single table).

                     

                    And everything SHOULD NOT be in one giant list. It needs to be in separate ones such as (to show in print):

                     

                    Equipment:

                          34bccsmnlg Heat Pump 100 SEER

                          0832jlvsdpi Air Handler 99%

                    Total: $1038423

                    • 7. Re: Multiple output lists in expanding body
                      philmodjunk

                      You need to post a screen shot of your relationships. Having seen it myself, I know that you can't just base the layout on a portal table as you have multiple related tables in a structure that rules out that option.

                       

                      You can print PO's as long as you can get them to work within the limitations of what can be done with portals.

                       

                      Otherwise, you are looking at a more sophisticated approach such as a special report table into which you import this data or the Virtual List approach.

                      • 8. Re: Multiple output lists in expanding body
                        Jason Wood

                        And everything SHOULD NOT be in one giant list. It needs to be in separate ones such as (to show in print):

                         

                        Equipment:

                        34bccsmnlg Heat Pump 100 SEER

                        0832jlvsdpi Air Handler 99%

                        Total: $1038423

                        Sub-summaries would give you this separation but yes I did miss that it was multiple tables so that's not an option.

                         

                        (And too much to manage on a single table)

                        I would be seriously thinking about whether this is really true. Having everything in one join table could have a lot of advantages (not the least of which would be for printing). There appear to be elements which are consistent, for example "amount", "description", and perhaps "quantity" if you have that. That doesn't mean you need to combine your Equipment and Accessories tables (although I would probably be seriously questioning that separation as well!). It just means your join table needs multiple foreign key fields.

                         

                        If you don't want to use a single join table, then I'd probably follow Phil's suggestion to look at a Virtual List approach.

                        • 9. Re: Multiple output lists in expanding body
                          tleitzke

                          There is way too much to just shove into 1 table Jason.

                           

                          Capture.PNG

                          That's the relationship tree.

                           

                          I have not found any sources on "virtual lists", where I can even understand what is even going on(Lacking in visuals and explanations and just showing the meat).

                          • 10. Re: Multiple output lists in expanding body
                            tleitzke

                            I have been looking deeper into virtual lists, and it is just everyone using portals - what you guys said to be not print friendly.

                            • 11. Re: Multiple output lists in expanding body
                              philmodjunk

                              Virtual Lists do not use portals.

                              • 12. Re: Multiple output lists in expanding body
                                tleitzke

                                Could you give me some sort of source for how I can do this? Every article I find is based on portals, and I do not know how to represent lists of data without a portal (I just tried "preview mode" of a portal, and no data. So I am guessing that's why portals are bad for printing).

                                 

                                What I understand so far is that a Virtual List is just a generalized list of several fields to store from any table by manually (script) moving the data over. However, I don't see the use yet since it only works on 1 table (as per all the examples I have seen).

                                • 13. Re: Multiple output lists in expanding body
                                  philmodjunk

                                  There may be portals in the example. There may be objects that look like portals and aren't actually portals, but for "virtual list" as I understand the concept, does not present that data in a portal, but rather in a list view of the data where the data from multiple sources as been pulled into that single list--sometimes using repeating fields to organize the data into a table like view. I really haven't had the need to use it, but have recently skimmed a tutorial and noted it's potential usefulness.

                                   

                                  You actually could use portals for your report as long as you work within their limitations. We steer people away from that option since a list view layout based on the portal is so much nicer, but your data model does not support that approach if you need to combine data from more than one of the tables that you have linked to Bids.

                                   

                                  You might also consider "mini-reports" that use data from just a few tables that are then appended into a single combined report as a PDF. Those mini-reports might then lend themselves to a list view type layout.

                                  • 14. Re: Multiple output lists in expanding body
                                    tleitzke

                                    Appending reports to PDF is my final option I want to save for last; because it will create a lot of blank space and waste paper by pushing each report onto a new piece of paper (Specially because some may just have a single line of data).

                                    1 2 Previous Next