Specifying the printer for REPORT FORM, without dialogue 1

[AndrewMozley]

This is a continuation of a thread from August.. The user has specified the printer which he wishes to use. I do not want to prompt for the printer when I print a sales order, because the work station is unattended.

My default printer is “Cutepdf Writer”, but for these sales orders the user wishes to use “Brother MFC-J5910 Printer”

I execute these instructions :

SET PRINTER TO NAME “Brother MFC-J5910 Printer”
TYPE Testfile.txt TO PRINTER
REPORT FORM salesord.frx TO PRINTER NOCONSOLE

I find that my Testfile does indeed go to the Brother printer, but the Sales order is still going to the default printer – the Cutepdf Writer. Why is this? It seems that the REPORT FORM command is not taking note of the SET PRINTER command. How can I get my sales order to go to the Brother printer, without displaying the dialogue box?

Thanks. Andrew

 

[JRB-Bldr]

If you do a Search within this forum for: set printer to
you will find a number of previous postings on the topic as well as the replies to address the issue.

Give them a try.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

Andrew,

Have you checked that the sales order report doesn't have a saved printer environment?

Assuming you are using VFP 9.0, open the report in the designer, and then open the Report menu. If the Printer Environment command is ticked, then that explains the problem. Remove the tick, and save the report.

If you are using an earlier version, then it's more complicated. In that case, let us know and we can talk you through the steps.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[AndrewMozley]

Thank you Mike

I am indeed using VFP9. I think you have solved my problem. There was indeed a printer defined for this report in its .frx file - the tag and tag2 field in the first record were both populated - although they referred to a third printer (which is not present on my machine).

When I cleared these - I imagine this has the same effect as un-ticking the Printer environment - the report went to the printer that I had specified with my SET PRINTER TO NAME command.

The logic of the REPORT FORM seems to be :

If there is a printer environment, use it; if the printer specified in the environment does not exist, use the default printer defined for Windows (XP).

If there is no printer environment, use the printer specified with SET PRINTER TO NAME.

If there is no printer environment and no SET PRINTER command, use the default windows printer.

Thank you for your help.

 

[Olaf Doschke]

>I imagine this has the same effect as un-ticking the Printer environment
Yes, VFP9 has that new option, so you don't need to apply this old hack anymore. It doers not totally clear the tag fields, but the printer info.

SET PRINTER TO NAME is sufficient to set the printer VFP prints to, if you donm't have specific printer info in an FRX. It's just automating Word or other apps will not see that VFP printer setting, they have their own or print to the default printer.

In fact setting the printer WITH a dialog simply can be done with SET PRINTER TO NAME (GETPRINTER()), since the OS dialog called by SYS(1037) has changed to not include choosing the printer, and so SET PRINTER TO NAME "name of a specific printer" is just skipping that visual dialog of GETPRINTER().

Bye, Olaf.

 

[JRB-Bldr]

You might also want to consider using the VFP Function APRINTERS() prior to your SET PRINTER TO... comnmand so that you can to ensure that the "Brother MFC-J5910 Printer" has indeed been installed on the individual workstations and has been named in a consistent manner so that it can be referenced accordingly.

Good Luck,
JRB-Bldr

 

[JRB-Bldr]

One additional note...

Brother MFC-J5910 Printer

I personally hate to see specific Printer Model numbers included in their 'Name'.

In light of how quickly printer models are obsoleted by the manufacturers and in-office printers are replaced with different model numbers, having a specific Model number included within the reference name is sometimes a problem - especially if this name is hard coded into an application.

You might be better off using a physical location or function designation in the name in lieu of a Model number (example: Sales Order Printer or Sales Office Printer ) so that if the physical printer were to be replaced with a new one having a different Model number, you would not have to change the application to match.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

JRB,

I completely agree with your point about using user-centric names for the printers. Looking around at the three printers in my office, I couldn't tell you the model numbers of any of them (and I'd have to think for a moment to remember the manufacturers' names). But I would instantly recognise "Main printer", "Colour printer", and so on.

I also agree with your suggestion of using APRINTERS() to get the names - but only in cases where you are not using the more common GETPRINTER(), which after all displays a combo box containing exactly the same names as those returned by APRINTERS(). And you should, of course, always avoid hard-coding the printer names, if only to avoid having to amend the code when the printer is replaced.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[AndrewMozley]

Thanks jrb, Mike.

I agree that it is undesirable to hard-code the name of a printer into an application, and I do not do that. In the present case I rely on the GETPRINTER() function which brings up a combo box to let the user select the printer for a particular class of document (Sales Order &c).

I take the point that it is a useful additional check to call APRINTERS() to validate the name of a printer before calling SET PRINTER TO. This is in case the selected printer has ceased to exist since the time (maybe months ago) when the user determined the printer for a class of documents. Thanks for that.

In the matter of printer names, I note what you say. I have always accepted the default name when installing a printer – because I never refer explicitly to its name in an application, but perhaps I should change the name to something simpler.

Andrew

 

[JRB-Bldr]

As Mike has correctly pointed out, GETPRINTER() and APRINTERS() yield effectively the same thing.

GETPRINTER() creating an interactive printer selection box and APRINTERS() merely populating an array for programmatic 'interrogation' - both containing the same printer names from the individual's workstation.

I have always accepted the default name when installing a printer – because I never refer explicitly to its name in an application

And yet here, by using the SET PRINTER TO NAME “Brother MFC-J5910 Printer” command - whether hard coded or derived from the user's GETPRINTER() selection, you are doing precisely that.

And, in general, the printer's default name during installation most often contains the specific Manufacturer and Model name - both things to consider avoiding.
Today its a Brother MFC-J5910
Tomorrow that printer might quit working and need to be replaced with an HP Model <whatever>

Regardless, its good that you got things working for your users.

Good Luck,
JRB-Bldr