Hi Héctor
>It's a fact "prompt" the printer has a bug that will never be solved... What I wonder is why works fine until a new printer enters the scene.

This is only partially true. VFPA does a great deal on this, has better Printer dialogue. Works like a charm.

#1 is your client altering the frx files
#2 is the printer environment stored to the frx
#3 I guess the receipt printer has a special layout (paperwidth) while the inkject / laser comes in Letter / DIN A4. You know you must have a frx for each layout (receipt / Letter / DIN A4 ) because the VFP Report engine can not scale the report. It might print on it, but the output is odd.
#4 (on REPORTBEHAVIOUR 90) If a report formerly running well (example old printer DIN A4 / new printer DIN A4) is scaled wrong, this means output is to wide, visible that the right boundary of the report is cuted off, it is not a problem of the printer. This is a problem of the report engine itself. This comes with the monitor. It happens when the monitor is of high DPI and the scaling of the display (systems main display) is larger then 100% (if lower the out put would be to tiny, but this is rare) There are two solutions on this
---1 turn the main monitor to 100% scaling, or use a different monitor with 100% scaling as main monitor (a bit odd on multi monitor systems, but the one in the front must not be main)
---2 use VFPA

I recommend VFPA.

You can raise this problem simply changing the scaling of your screen, reopen VFP and run a report (REPORTBEHAVIOUR 90)

Lutz

>>>Hi friends:
>>>
>>>My system prints using 2 kind of printers. One is a receipt printer and the other a inkject or laser.
>>>
>>>Everthing goes fine until my client, very happy, buys a new printer, install it and try to print a large list of articles in the laser and the width is as the receipt printer losing all at the right...
>>>
>>>My instruction is
>>>
>>>REPORT FORM MYLIST TO PRINT PROMPT.
>>>
>>>Apparently uses the selected printer for printing but the default printer design...
>>>
>>>report "Printer environment" is not checked as I've learnt many year ago.
>>>
>>>If I close my app and run again, and go directly to print the list it works ok, but if I print a receip first... it's the end of the world
>>>
>>>I insist, everything went ok until client put his hands on it... grrrrr.
>>>
>>>Any idea?
>>>
>>> Héctor
>>
>>Have you tried to store the printer settings. this is outside the report?
>>One can switch the printers (and there settings) using SYS(1037,n)
>>With this on can create an (external to the frx) set of printer stuff that can be loaded in front of REPORT FORM.
>>There are some articles out dealing with this. There is some dealing with frx files needed
>>If you need help, I can try to show how I do this.
>>
>>Lutz
>
>Lutz:
>
>At first many thanks for answering me.
>
>I don't know what you mean about dealing with this. Before posting my problem I though I should save the system default printer and just before "REPORT FORM..." execute "SET PRINTER TO NAME mySavedDefaultPrinter" and that would solve my problem. But perhatps there was another secret for this rare behavour.
>
>It's a fact "prompt" the printer has a bug that will never be solved... What I wonder is why works fine until a new printer enters the scene.
>
>Dankeschön
> Héctor