Bin problems with the FWH27 printer class

[Marco Turco]

Hi,
with the new FWH27 EMF printer class
the print output go always on the same bin scheet
instead the default bin scheet.

There is no problem with the old WMF printer class.

Any solutions ?

Thanks in advance

Marco Turco

[Richard Chidiak]

Hi,
with the new FWH27 EMF printer class
the print output go always on the same bin scheet
instead the default bin scheet.

There is no problem with the old WMF printer class.

Any solutions ?

Thanks in advance

Marco Turco

Antonio

I confirm the same problem

Richard

[Antonio Linares]

Marco, Richard,

We have tested it here on a Canon Pixma MP750 and it works ok (samples\TestPrn2.prg).

What you can't do is to change the printer bin once you have initialized the printer in your application, unless you directly call the function PrinterEnd() that will force FWH to initialize again the printer object with the new default printer settings values.

[Marco Turco]

Hi Antonio,
I don't want to change the bin from my app,
I want only that my app will print on the default bin as set on the printer panel.

The tprinter class has to check which the default bin is
and print on this bin.

Marco

[Richard Chidiak]

Hi Antonio,
I don't want to change the bin from my app,
I want only that my app will print on the default bin as set on the printer panel.

The tprinter class has to check which the default bin is
and print on this bin.

Marco

Marco

We need both. The print panel must show the default bin as set on the printer panel and we need to be able to change this bin. This is the standard windows behaviour. This was working before.

Richard

[Antonio Linares]

Marco,

What I mean is that if you change the default bin _meanwhile_ your app is running, then FWH will not respect it unless you do a PrinterEnd() and a PrinterInit(), so the print values used by FWH get properly intialized again.

[Richard Chidiak]

Marco,

What I mean is that if you change the default bin _meanwhile_ your app is running, then FWH will not respect it unless you do a PrinterEnd() and a PrinterInit(), so the print values used by FWH get properly intialized again.

Antonio

The initialisation should happen every time we call printersetup, all printer params must be reinitialized at that moment.

Richard

[Marco Turco]

Antonio,
I never set the bin from my app.

I try to explain me better:
imagine that the printer has two bins: the bin1 and the bin2,
the customer set as default bin the bin2 (he make this setting into the Printer control panel calling Start/Printers and fax).

After, the customer execute my app, and try a print.
Well the print output will not start on bin2 (the print default bin) but on bin1.

This is the biggest problem.

Marco

[Antonio Linares]

Richard,

Yes, we should initialize the low level structure everytime PrinterSetup() is used.

But what happens if the user sets a different bin manually, from Windows printer settings ? In that case, the application is not aware of such change.

[Antonio Linares]

Marco,

>
After, the customer execute my app, and try a print.
Well the print output will not start on bin2 (the print default bin) but on bin1.
>

We have tried that exactly this morning and it worked ok. We started the app after the bin was manually changed. All ok.

What we are checking now is how to detect such bin change if it is performed meanwhile the app is running.

[Antonio Linares]

Marco,

Our tests were done with samples\TestPrn2.prg and they worked ok. The printing was properly done on the control-panel-printer selected bin.

[Marco Turco]

Antonio,
I have found the problem.

I have in my app a button to give the possibility to the customers to change the printer parameters (eg. the bin scheet).

This button call the shprnproperty() function you introduced with these latest FWH's releases. Well, when I change the bin using this function, the change doesn't applies to my app. I replaced now the button action calling the old PrinterSetup() function that runs fine.


Marco

[Antonio Linares]

Marco,

Thanks for the feedback,