I am struggling to come up with the best way to handle print layouts for my database. My difficulties can be summed up in two situations. The photos I think is the easier of the two to resolve. The harder one would be a whole record report with three related tables.
Photos
Photos is not really an issue of printing them but on how I want them printed. I would like to have it be six photos per page in a 2x3 arrangement. Currently I am just making layout 1-6, layout 7-12, etc. While this works I am sure there has to be a better way that is more dynamic.
What I am currently thinking about doing is making a print layout with global fields and then just populating them before printing and then just loop though however many I need to.
I am also thinking about ways I could use the relationship and a global filed to define what is printed but I have yet to formalize how this might work.
Whole record report
When printing the whole record I have three related tables that normally only have one related record but some times can have multiple or none. The records have a lot of data and one related record can take up half a page or more. My current solution only prints the first related record per table and if there is no related it prints an empty page (not my best work).
My current plan will be to have the different tables printed on there own layout allowing me to print as many as needed like I do for photos. But this will leave a lot of pages only half filled and I fell will not be all that much better then what I have now as far as presentation go's.
Dose anyone have any advice on how you handle print layouts? Please let me know if I need to provide more details and thanks in advance for your help.
Photos: Why don't you use columns? Design a three column landscape layout that has a body height that allows two records per column, or a two column portrait layout that allows three records per column. With that you can print any number of images, whether it is 3 or 300.
Whole Report: This is more difficult because you have multiple data sources. FMP is not a page layout tool and it sucks in this situation. Accepting the presence of white space might be the most pragmatic. If you try to solve the problem inside FMP you'll have to jump through a lot of hoops and it's still not a page layout tool.
I never even looked at columns before. I kinda in the back of my head knew they excited but not once had I ever considered using them. You have made my day! What a wonderful solution. So glad I asked for help.
I will leave this unsolved for now in hopes someone will have other suggestions for the whole report. I am not holding out a lot of hope though. I think you are right that when it comes to this issues FileMaker has limited ability.
Whole record report
Collect your related records into a virtual list and print from there, use header/footer for data of the main/root table. Maybe best done record for record in a script loop.
What is a virtual list? I think I might see what you are suggesting using header footer vs main. Over all though I am not exactly sure what you have in mind any chance of more detail?
I was also considering using appending to PDF and I just need to try it to see how it works. I was assuming it would not fill in empty white space but just add pages. Still might be what I end up doing though.
On the other hand… the MBS plugin has PDF functions that may more closely match what you are trying to output. Care to chime in @MonkeybreadSoftware?
"Virtual List" is a technic to collect data into a $$variable and have a table with un-stored calculation fields extracting rows and columns out of it. There's a lot of knowledge about it here:
You can always check DynaPDF functions in MBS FileMaker Plugin. e.g. check the Catalog or Invoice examples on how to build a PDF from scratch with tables for layouts.
I have a unhealthy reluctance to use plugins but it seems MBS has a solution to all my problems. I am guessing one of theses days I will have an issue that is so important to me that I will let the flood gates open and try MBS and never look back. I will check it out though and thank you for letting me know this is always an option.
Thanks it looks like I have been doing it without knowing what to call it. But that is far more advanced then what I have done. Thanks for posting the link I will look into it. Always more to lean it seems.
a) define a global text field for each related table that fits that description. For sake of example I will call these g.TableA and g.TableB
b) In your report print script, go to each related table (if there are indeed related records) and loop through them setting g.TableA to itself, a hard return (except for the first time*), and the current related-record value of whatever field or fields you want on your report. When you're done with loop, g.TableA may look like this for a situation in which you had three Table A related records:
1/12/15 - Purchase of greasy widget for project
1/14/15 - Installation of widget in appropriate grommet
1/17/15 - Routine assessment of widget bolt torsion
c) On your report layout you use a merge code (menu Insert/Merge Field). Once you have added it, it has text object "handles"'; you grab the lower right one and drag down to make it as tall as need be to accommodate a boatload of Table A related records. The in the Inspector you tell it to slide up and also reduce the size of the enclosing part.
Now when you print a record that only has one Table A related record, the printout will contain just that one line, and not take up additional room full of empty space. But when you print a record that has three or four Table A related records the report will expand in that printed space to make room to handle all three, which have all been "harvested" into that one global text field.