I've struggled over the years to come up with a decent system for
previewing printouts on FileMaker. In the data-entry layouts, I
always turn off the status area and give users a decent button bar
across the top with navigation buttons and record information to
replace FM's rolodex. But in Preview mode buttons don't work, so you
have to either show the status area -- which a lot of users find
confusing -- or set up a preview layout.

Lately I've gone with the latter arrangement, creating a dialog-style
layout with an 8-1/2"x11" container in the center where I paste an
image copied from the printable layout. The same navigation buttons
users know from the data-entry layouts allow them to page back and
forth through the report, using a script that goes to the printable
layout, finds the correct page, and returns to the dialog layout to
paste it in the container.

But as simple as this system is, it's prone to a lot of the blinky
behavior I work so hard to avoid in FileMaker. "Freeze Window"
doesn't seem to freeze at all, so that there's a lot of flashing
screen activity when users page through a report. I thought perhaps
someone out there could recommend a better system.

Just to explain how mine works, in a nutshell:

1. Users click the Report button in the button bar, which takes them
to a dialog layout that lists all the available reports. Sometimes
there are additional options -- custom report title; time span
options; a selection of headers and footers, letterhead or plain
paper, etc. -- but essentially at the center of the layout is a portal
with report titles set to look like buttons.

2. The user clicks a report and a script runs an error check to make
sure it has everything it needs for that report, then opens a new
window exactly the same size as the original in exactly the same
position called "Report," goes to the appropriate record(s) in the
layout to be printed, displays it in preview mode, makes a copy, gets
total page count, then opens a third window exactly the same as the
second called "Preview," pastes the copy of the first page of the
report in the container, sets the page count info for navigation, and
pauses.

3. If a user wants to see the first, previous, next or last page,
they click a navigation button and the script returns to the "Report"
window, pages to the correct page, copies it, returns to the "Preview"
window, and pastes it in the container.

All of this works great and has a lot of advantages: the user's found
set never changes in the first window, so there's no disruption to
their workflow; the multiple windows allow the script to be modular,
so that very little has to be done to add a new report or update the
process; and having the records that are being reported on located in
the second table allows the script to be efficient without also
sacrificing the navigation features the user is used to.

But it has some downsides, too, the worst being the flashing of
layouts that I mentioned above -- and on a slow network connection,
it's especially bad. Even if I set "Freeze Window" when going from
the report dialog to the preview dialog, FileMaker still displays the
center window where the printable report is compiled. And more
disconcerting is that when users page forward or back, there seems to
be no way to keep that middle window from appearing, which makes it
look like the report is bouncing around the screen.

Now none of this is functionally problematic, but since the user
experience is at the center of database management systems, wouldn't
it be good if Freeze Window actually froze the window? Or -- since
there are multiple windows in operation here -- perhaps FM needs a
function called "Freeze Display" that actually freezes the display
until you unfreeze it or set the script to Pause.

Or perhaps someone has a better system that circumvents these
problems. Anyone? Anyone? I'd love a good workaround for previewing
reports.

Thanks in advance for any suggestions.

Best,
-J.

On 2009-11-21 19:47:35 -0800, jahn <jahnbigbooty (AT) yahoo (DOT) com> said:

Your previewing issues are solved in one swoop with an upgrade to FM10.
The new "Preview subsummary reports in Browse mode" feature means that
you can see subsummaries AND edit data at the same time. All buttons
remain functional. If an edited record belongs in a different sort
category, editing the category data will move the record, and
resummarize the affected totals.

Freeze Window has always worked better on Mac than on Windows. This is
an OS level issue. All developers wish that the flashing and
non-freezing behavior would be fixed on Windows. So far, it has not.
However, you're hopping hither & yon in many different windows in order
to try to mitigate other problems such as no workable buttons in
Preview. If you could stop doing that, much of your Freeze window issue
would resolve.

You can still assemble reports in a separate window (including ones
off-screen, at negative locations or extremly large positive locations,
which obviates redraw and thus flashing) so as not to touch the
original found set in the original window.

Download a demo version of FM10, convert your current files (a copy of
them, of course) and give a subsummary report in Browse mode a tryout.
See if it doesn't resolve a whole bunch of issues for you.
--
Lynn Allen
--
www.semiotics.com
Member FBA
FM 10 Certified Developer

Hi, Lynn -

Thanks for the reply. I usually include OS and FM version in my
posts, but forgot. I am in fact working in FM 10 Adv on Mac OS X. I
do like the the way subsummaries work in Browse mode, but this doesn't
affect other differences between reports in Browse mode and how they
print, including sliding (probably the most important factor), or the
way headers, footers are displayed. For this reason, Preview mode is
the only way to give users an accurate representation of what the
report will look like, especially when working with data in related
tables or even multiple related tables.

I agree that generating multiple windows is causing much of the
problem, but it's a trade-off I make because it maintains a consistent
user-interface, provides the ability to put the functions my users
need at their fingertips, creates a modular script that's easy to
build on and administrate, and maintains the user's found set in the
table they're working on, which reduces confusion when they return to
the starting layout. The goal I'm searching for is to hang on to
these benefits while mitigating the downsides -- in particular, all
that flashing. I don't think there's any way to do that while staying
in one window, but perhaps someone out there has a good idea they
could share.

You write, "You can still assemble reports in a separate window
(including ones off-screen, at negative locations or extremly large
positive locations, which obviates redraw and thus flashing) so as not
to touch the original found set in the original window." I'm not sure
how this would work. Can you explain in more detail? I'm not
familiar with the terms "negative location" or "positive location,"
and I don't know how one assembles reports in off-screen windows.
However, this may be the solution I want. How does it work?

Thanks again for your help.

Best,
-J.

On 2009-11-23 10:07:08 -0800, jahn <jahnbigbooty (AT) yahoo (DOT) com> said:

If part of your process involved spawning new windows to assemble,
process, sort or do other things to the report data, part of the "New
Window" command allows you to specify where the window is located on
the screen, relative to the 0,0 point of the upper left corner.

If you specify 100 pixels down and 100 pixels right, the new window
will spawn that many pixels down & right from the corner of the app
window.

If you specify -1000 pixels to the right, the window will spawn way way
way to the left (the not-right). In some versions of FM, 9 or 8.5 I
think, this negative specification did not work. I think it does again
in 10, but could be wrong. It's an undocumented use of the window
positioning function.

In that case one can specify immensely large pixel measurements to the
right, so the windows are fully off-screen and do not require drawing.
If you then want the user to see that window, after all operations are
done, you can reposition the window into the visible desktop.

This may quell some flashing. It may not.

--
Lynn Allen
--
www.semiotics.com
Member FBA
FM 10 Certified Developer

Holy smokes! Just the solution I needed. I'd been opening the new
windows in the same location and dimensions as the original window so
it wouldn't look like there was more than one window open at a time.
However, the movement from the "preview dialog" window to the actual
preview window was causing the display problem. I had no idea you
could open windows off-screen. Now there's no change at all in the on-
screen display. Wow. Fantastic. I feel like I've finally found my
perfect report system. Thanks for your help with that. That was big.

Much appreciated,
-J.

On Nov 22, 3:47*am, jahn <jahnbigbo... (AT) yahoo (DOT) com> wrote:
Hello Jahn

I agree , expecting the user to press “continue” button in the status
area (status toolbar) after previewing is not intuitive. I like Lynns
off scree window adjustment tip too, it will be great if the tip works
for my floating dialogue windows that always seem to appear unshaven
and bleary eyed e.g. with the tab the user was last in and old info
entered into globals prior to the script tidying everthing up for
use.

Getting back to print preview, here’s an alternative approach which
might be of interest to some. It does away with the need to copy and
paste graphics for each page in turn. This approach uses the print
preview layout with the status area hidden. Next to it is another
window with the necessary controls for moving between pages, selecting
type of printout etc. Here’s a link to the screen grab of the two
windows:
http://www.imagefrog.net/show.php/49...cePreview2.jpg One
refinement that I’ve not got around to doing is adjusting the found
set in the preview window to simulate the change between “current
record” vs “all records”.

Regards
Kevin Smith