Actually, I notice they don't necessarily all come out landscape. How they come out depends on the order of the creation of the report.
When I chose them in the order of Landscape, Portrait, Portrait, the landscape report came out cropped in portrait mode.
Either way, some of them are stretched in a funny way, which resolves itself if I click the window's page setup button and choose the proper orientation.
Sometimes, the orientation is ok, but the text on the page is stretched. This too resolves itself when I choose page setup on the preview window and re-click the (already selected) proper orientation button and click OK.
What is up with this?
Your sample doesn't seem to work as mine does.
I have a script and a layout for each report. In the script, a new floating window is opened, the layout is chosen, and preview mode is turned on.
I could call each script on its own, but instead I have a "tick list" form in which I choose the reports I want. Then, after I've picked and accumulated my $$list, the main script calls the other ones, depending upon which reports I've chosen.
It works fine when I open 1, or even if I open 2 different ones with the same orientation. The problem occurs when I open two or more windows with different orientations. It seems the orientation of last one opened trumps all of them, and they switch their orientations.
Well, my script also has two layouts with different orientation and switches between them. The important thing is to select the appropriate orientation for every layout before exporting the records. Then the order in which you print shouldn't matter.
Why don't you post your file, or the script?
At first I thought there was a problem with my scripting. I wanted the individual reports chosen to be open in their own floating windows. I'm attaching a copy of one of the scripts. On this particular script the report is portrait, so the print setup step specifies that. Another report is landscape, so ditto for the print setup step.
I have a more complex way of calling these scripts using a layout with the "tick list" trick to build a list of reports, then closing that selection layout, and processing the list from my main contacts form, so the reports are in proper context. I wanted the report selection layout to be modal until I either click OK or Cancel, then return to the script to process what I selected. Unfortunately, I discovered that even if you open a layout modal, it doesn't stop the calling script from continuing on. This is not ok in this instance, so I used this trick (http://kallesamuelsson.blogspot.com/2012/11/modal-windows-in-filemaker-12.html) to force the script to pause until my report selection is competed.
I thought this was causing my issue, but it turns out that even if I run the individual report scripts from the script menu, it occurs. I execute a "portrait" report from script menu, and it opens the window just fine. Then I execute a "landscape" report from script menu, and it opens its window just fine. But, underneath that, the "portrait" window is auto-magically switched to landscape mode. This happens vice-versa if I open the reports in the opposite order.
Further research shows that with both floating windows open, if I manually click the page setup button and switch to the proper orientation, BOTH windows switch. This seems to be the heart of the problem. Switching orientation in one floating window seems to affect all open floating windows.
You obviously know much more FMP than I do. Would you try opening your reports in new windows in preview mode and see if you get the same results? No exporting is required to reproduce this behavior. It would be good to know if this is the expected behavior. It seems like a flaw to me. Why wouldn't you be able to adjust each independent floating window on its own? Further, if this is the way FMP is supposed to work, I will not be able to open multiple reports for my users.
Granted, for exporting purposes I could open a window, export it, save the name, close the window, rinse and repeat, then when done, combine or ZIP the PDF files in the list. The problem doesn't occur if you close the floating window before opening the next one. But that means I can't just open multiple reports for the users to view (without exporting). Big limitation, no? I guess I could always export to individual PDFs, then open them in the default viewer. That should work, but I'd accumulate a LOT of files that would have to manually cleared out eventually.
EDIT: Now that I think of it, there was no need to use the "modal" trick. I could have simply opened the selection window modally and built my $$list, then if Cancel button pressed do nothing, if OK button pressed, THEN run the script to generate the report(s). Duh! Still, this doesn't affect the real issue here.
Voila_Capture78.png 139.8 K
Have you tried editing your script to say something like
print setup [portrait mode]
print portrait reports
print setup [landscape mode]
print landscape reports
Thanks @Aryden. If by "print portrait reports" or "print landscape reports" you mean immediately print them instead of displaying them in the modal window and allowing the user to actually print, then no I haven't. Actually, that is pretty much what I'm doing now, except opening them in floating windows instead of printing. The business use was to display the report(s) and the user could view and/or print as needed. Once they are opened in floating window(s), the last opened window's preference on orientation trumps all others, and they all switch to that orientation.
As mentioned earlier, if I'm only opening them in order to export and possibly merge or zip, then no problem, I simply open, export and close each window before opening the next. If I just want to open 2 or more reports for the user to view, this is a big issue if 1 portrait and 1 landscape. This seems like a big flaw in architecture, doesn't it?
Thanks for the reply.
Once they are opened in floating window(s), the last opened window's preference on orientation trumps all others, and they all switch to that orientation.
… if they're in Preview mode. Depending on the contents of the windows, Browse mode may be sufficient to preview the print, and there is no cross-over in Browse mode, because Print/Page setup doesn't impact the display there.
Try the following: open your modal windows in Browse mode and use Window Adjust [ resize to fit ]. in List view, this will maximize the window to screen height, but the width is exactly that of your layout, so the user will see a vertical list of pages in portrait or landscape mode, depending (where this mode is an attribute of the layout, not a function of the Print Setup).
When they decide to print/export (and now that you're using Browse mode, you can even offer them a functional button …), switch to the correct orientation, print/export and close the window - or return to Browse mode. (You may need to use a custom menu and tie the Print command to a script be able to use Print Setup in preparation.)
Ok, this seemed to work. I first tried just displaying the report in browse mode and removing the print setup step. When they exported however, they were all landscape. So I re-read your comment and put in a print setup step before exporting, and that solved the problem. I needed to add a field in the reports table indicating each report's orientation, and save that to another $list variable during the step which accumulates the reports to print. Anyway, you get credit for this answer. Thanks a bunch.
Frankly, I think this is an oversight in FMP. If you have a seperate window for each report, you should be able to set the preview orientation for that window only, not have it propagate to all open preview windows.
Slight extra question: Since the Print Setup step brings up a GUI dialog, I guess there is no way to script the orientation in one step, right? I had to say
If $orientation = "portrait"
Print Setup (with portrait selected)
Else If $orientation = "landscape"
Print Setup (with landscape selected)
Am I missing something, or is this just how it needs to be done?
Thanks again for solving yet another issue for me.
Since the Print Setup step brings up a GUI dialog, I guess there is no way to script the orientation in one step
Not per se, but you can fake it by writing a dedicated sub-script, e.g. PrintSetup_SP [ portrait | landscape ]
Set Variable [ $sp ; Get ( ScriptParameter ) ]
If [ $sp = "portrait" ]
Print Setup [ with portrait selected, Perform without dialog ]
Else If [ $sp = "landscape" ]
Print Setup [ with landscape selected, Perform without dialog ]
Show Custom Dialog [ "Alert!" ; Case ( IsEmpty ( $sp ) ; "Missing" ; "Invalid" ) & " parameter!" ]
that you call from your main script with $orientation as parameter. Write once, use often …
Thanks, calling a sub-script good idea. I forgot to put perform without dialog in my post, but I did use that.
Also, until they fix the bug (I think it's that anyway), I also keep an $allSame variable which tests my list of chosen report orientations, and if true, then I go to preview mode for each window. Reason being, users are much more comfortable with preview mode when viewing the report.
Thanks for all of your help. You da man/woman/AI-entity.