A mild printing crisis in bound solution

[Lou Lesko]

We are getting ready to release a stand alone solution and seem to have come
upon a little problem.

The solution is going to be run on OS9 OSX and Windows.

The problem ocurred in OS 9, the user went to print using a scripted button and
she got a print of the source layout instead of a print from the designated
print layout.

The only thing I can think of is that the Page Setup Setting were lost. In
reading some other articles from the filemaker group archive it doesn't seem
that the page setup settings stick with the stand alone solution.

If this is indeed the case, what work arounds have you found. Should I be
building a page set up step into my printing scripts?

Just an aside, this solution went out to mostly OSX users where we didn't have
any problems is this an OS9 issue or were we just lucky in that everyone had
Epson printers and there for the drivers were similar not causing any headaches.

Thanks

Loulou

[Lynn allen]

Lou Lesko <lou@NOSPAMlouislesko.com> wrote:

> We are getting ready to release a stand alone solution and seem to have
> come upon a little problem.
>
> The solution is going to be run on OS9 OSX and Windows.
>
> The problem ocurred in OS 9, the user went to print using a scripted
> button and she got a print of the source layout instead of a print from
> the designated print layout.
>

Usually one builds separate scripts for 4 different setups, Landscape
Multiple, Landscape Single, Portrait Multiple and Portrait Single. Then
these modular scripts are called whenever they are needed within other
navigation and print scripts. To build each, manually set each setup
and choose "Print current record" or "Print all records being browsed",
then open the script and let it store the settings by selecting
"Replace" for the page setup step.

What most people don't know is that Filemaker will store DIFFERENT page
set up data in the same script for each platform. Page setup will not
work reliably cross platform so you have to re-do and re-store those
settings on OS 9, again on OS X, and once again on Windows. You can use
the same script, but you have to do it three times, once on each
platform.

On Windows, you can also store other page setup information, such as
selecting other trays, other than default printer & things so be
careful. You don't want to have users getting messed up. The Mac
doesn't store as much info.

This is why I ALWAYS show my users the print dialog box. That way if
something is momentarily wrong, they can still change settings for page
orientation, copies, etc, until I can get there to service them and make
it print the way it should.

--
Lynn Allen Allen & Allen Semiotics
FSA Associate Filemaker Consulting & Training
[email]lynn@semiotics.com[/email] [url]http://www.semiotics.com[/url]

[Helpful Harry]

In article <slrnboe84a.iao.lou@sdf.lonestar.org>, Lou Lesko
<lou@NOSPAMlouislesko.com> wrote:

> We are getting ready to release a stand alone solution and seem to have come
> upon a little problem.
>
> The solution is going to be run on OS9 OSX and Windows.
>
> The problem ocurred in OS 9, the user went to print using a scripted button
> and she got a print of the source layout instead of a print from the designated
> print layout.
>
> The only thing I can think of is that the Page Setup Setting were lost. In
> reading some other articles from the filemaker group archive it doesn't seem
> that the page setup settings stick with the stand alone solution.

<Snip>

The Page Setup command doesn't store any layout information, just the
normal Page Setup window details (portrait/landscape, A4/Letter, etc.),
so this can't be the source of your printing the wrong layout problem.

The script needs to have the Go To Layout command before the Page Setup
and Print commands so that it goes to the appropriate layout for
printing (you may want a Freeze Window beforehand too so that the user
doesn't see the layout switch). Once it's done the Print, you need a
second Go To Layout command to go back to the original source layout.

If your script already does go to the correct layout before printing,
then this sounds more like a case of "User Error". Choosing Print from
the FIle menu or pressing the Apple-P keyboard shortcut will simply get
a printout of what's on screen (for X number of records). They need to
use your button/script instead.



As a side note, the Page Setup command is only stored for the CURRENT
printer. If the person using your standalone solution has a different
printer then the stored Page Setup information is irrelevant and the
page setup uses the default instead (usually Portrait, Letter sized
paper).

This means that each Page Setup needs to be re-stored for the user's
printer (and again if they change printers), which of course is
impossible for something like a Shareware or Commercial soultion.

This is NOT a FileMaker problem, but a printer driver "standards" one
and happens with any documents you receive from other users and is also
why the MacOS tells you to check the Page Setup in any open
applications if you change printer drivers.



Helpful Harry
"Just trying to help whenever I can." :o)

[Lou Lesko]

Lynn and Harry, thank you both for your responses. Incredibly informative.

Harry, the scripts are set up as you explained with all the steps in there
proper place.

In Lynn's post, I did not do a seperate save of page layout settings for each
platform, so I'll definitely be pursuing that. This maybe contributing to my
problem. The bound soution does not have any menu's enabled so that rules out
user error.

But there was a problem I ran into a while back in my OS9 days, when you went to
a db to print and then put a "Toggle Window [Hide]" step in at the end of the
print script before going back to the original layout in the originating
database, Filemaker would print the originating layout much like my current
problem. I remember that this problem occurred with a product called
print-to-pdf. It was almost as if the script moved too fast for the print
driver to get the proper information.

However, the good news is that I don't think that I'm going to have to put a
Page Set-Up script step in. Lynn, I too always have my solutions utilize the
print dialog.

Again thank you both and if I find out any new details, I'll post them. If you
have any further thoughts, they would be much appreciated. But I think Lynn's
observation of saving the Page Set Up for each platform is going to be the
answer. This is a commercial product so I hope this is the answer.

See you two around the block.

loulou

[Lou Lesko]

>

> As a side note, the Page Setup command is only stored for the CURRENT
> printer. If the person using your standalone solution has a different
> printer then the stored Page Setup information is irrelevant and the
> page setup uses the default instead (usually Portrait, Letter sized
> paper).
>

Just to add a bit more info. I kept this in mind durring development and
designed the layout to be a standard A4 Portrait, so it would work across all
the printer drivers.

Thanks again

loulou

[Chris]

in article 1g2mi70.13nj1861jq0irsN%lynn@NOT-semiotics.com, Lynn allen at
[email]lynn@NOT-semiotics.com[/email] wrote on 11/10/03 1:22 am:

>
> This is why I ALWAYS show my users the print dialog box. That way if
> something is momentarily wrong, they can still change settings for page
> orientation, copies, etc, until I can get there to service them and make
> it print the way it should.

Or place a "Use Page Setup when printing" checkbox in a preferences file,
which gives the user the option.

Chris