Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Network printers
Message
 
À
21/08/1997 09:52:22
Information générale
Forum:
Visual FoxPro
Catégorie:
Problèmes
Divers
Thread ID:
00043337
Message ID:
00046180
Vues:
36
Universal Thread Visual FoxPro forum wrote:

> [From: John Dennis To: Marc Grajower]
>
> >John,
> >
> >Hope this is not too late ...

> >Your problem is caused by the fact that reports in VFP have the
> strange

> habit of overwriting current session settings, with the settings as
> set
> when you last recompiled your report or your session.
> >
> >But there is a way around this, it involves a little hacking. Here's
> a
> posting I wrote back in January. It should contain all you need:
> >
> >
> >Here's what I see when I open a report as a .dbf (USE
> reportname.FRX),
> > and open the EXPR memo of the first record. As far as your problem
> is
> > concerned I think it is the Alpha-Omega of the report writer setting
> in
> > Windows. (BTW everything that I explain here assumes HP like
> printers).
> >
> > DRIVER=WINSPOOL
> > DEVICE=hp 5l
> > OUTPUT=LPT1:
> > ORIENTATION=1
> > PAPERSIZE=9
> > COPIES=1
> > DEFAULTSOURCE=1
> > PRINTQUALITY=0
> > YRESOLUTION=300
> > TTOPTION=2
> >
> > When at run-time a report is launched, the settings contained in
> this
> > field overwrite the windows settings. How much control the PROMPT
> > clause gives you over this I frankly do not know.
> >
> > You can change these settings (or erase them if you want the current
>
> > settings of Windows), but you have to hack the .frx, so this is not
> End
> > User oriented (one could argue that it is not oriented at all :-)).
> >
> > Now if you empty the TAG and TAG2 fields and the report is part of a
>
> > project, and you recompile it, then your hacking will take effect.
> >
> > Careful, if you load the report back into the designer, you modify
> > something (even if it is not related to the printer settings) and
> save
> > your work, your hacking will be overwritten again, the report writer
>
> > assumes rather humoristically that you will run the report in
> exactly
> > the same circumstances as when you save the report, so it just sets
> > the settings of that moment into the field above.
> >
> > To recompile my projects I have this little program that BUILDS ...
> .
> > Before this I have a loop that empties out the Expr, Tag,Tag2 fields
> of
> > the first records of all the .FRXs. I keep the YRESOLUTION= 300
> > (because this forces your printer in low resolutions which is great
> for
> > speed!), and if I want the report to print in landscape, I set the
> > ORIENTATION=1.
> >
> > Those settings that are absent at compile time can be set at run
> time.
> > For example, if you want your user to be able to fax a report i.o.
> > printing it, you leave out the DRIVER, DEVICE and OUTPUT statement
> from
> > the EXPR field, and you SET PRINTER TO, or use GETPRINTER or
> sys(1037),
> > before you REPORT FORM. Other Windows settings can be set using API
> > routines, but I've other thing to do ...
> >
> > All this works of course for reports that are integrated into a
> project,
> > and have not to be changed at run time. To allow for that
> functionality
> > my suggestion would be (as Dave says) to use another tool... The
> Report
> > Writer is definitely not an End User tool, at this point in time.
> >
> > HTH,
> >
> > Marc.
>
> Marc:
>
> It is indeed not too late.

That's cool!

> I am neck deep in this rather frustrating
> project, and it revolves around sending two print jobs to these to
> different printers

That's not cool! :)


> . Your info is exactly what I have been hoping to find,
> but not even the KB has anything like what you spelled out for me
> here.
> Thanks a heap!!! One other question, if I might be so presumptious.
> I
> also need to set up a page with an abnormal page size, but can't
> figure out
> where that setting is made. I can chancge the page size in the page
> setup
> and then printer setup, but that is a mess. Can you assist?
>

I'm afraid I cannot. I guess through the WinApi you could solve the
problem, but I think it is not worth it. Maybe you could make one
report object for each configuration and call the one you need at
runtime (maybe by identifying the station). Not very elegant, not very
dynamic, but nobody has to know.

And I thought that I knew it all ... :)

Marc

If things have the tendency to go your way, do not worry. It won't last. Jules Renard.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform