Preview an A4 report when default printer is a small SLIP printer 3

[Rajesh Karunakaran]

Dear Friends,

I have a report designed for A4 size. When my program runs in a system where the default printer is a SLIP printer, this report shown cut because the default printer paper size doesn't have that much width. I cannot change the default printer as it is requirment of another software running on same system. How can I handle this? I want the report to be shown on preview properly. Setting the default printer to one with A4 size, just before sending the preview command, may be a solution?

Thank you in advance.
Rajesh

 

[StefanFoerner]

Hi Rajesh,

please try the following:

printerName = "HP Color LaserJet"    && an installed DIN A4 printer
or: printerName = GETPRINTER()       && to select a DIN A4 printer

reportName = "my_report"             && Your report to print

SET PRINTER TO NAME (printerName)    && set the printer for Your VFP-App only

REPORT FORM (reportName) NOCONSOLE TO PRINTER                       && print directly
or: REPORT FORM (reportName) NOCONSOLE PREVIEW TO PRINTER           && print with preview
or: REPORT FORM (reportName) NOCONSOLE TO PRINTER PROMPT            && print with printer selection
or: REPORT FORM (reportName) NOCONSOLE PREVIEW TO PRINTER PROMPT    && print with preview and printer selection

Regards, Stefan

 

[Rajesh Karunakaran]

Hi Stefan,

Thank you.
I know these methods you explained. But I want to make it generalised, ie in each and every case I wouldn't know which A4 compatible printer the customer has installed in his system. So, I was wondering if there is a setup which we can expect in all Windows systems irrespective of which A4 printer the system has its default or otherwise so that I can set to that and reset it when the reporting is closed.

I think, better I would go for a feature where the customer can specify a particular printer which should be used as a base for all previews. If the customer specifies it, I would set that printer just before the reporting. Otherwise, I wouldn't do anything in which case the report may appear cut if he has any small printer as default.

Thank you once again,
Rajesh

 

[Olaf Doschke]

The only thing you can do is provide the user a way to set the printer used for the next reporting. And that is simply SET PRINTER TO NAME GETPRINTER().

Users know wht format they expect of a report, so they know they want to select a A4 printer for an A4 report. If your software is a pos system typically printing slips, then that printer choice menu item may also be a configure A4 printer.

It's very general: If you can't know something upfront and automatic, provide a way for the user to specify. For one type user convenience ask him once and store as config, for another type of user convenience allow him to change the setting anytime. Such a printer choice menu item is ideal for that. Also with SET PRINTER TO NAME something you don't set the default windows printer, so no other applications are affected, just this one VFP applicaton process.

And forget about automatically determining A4 printers. You may think you can find out such settings. Well, there are certain API calls, yes, but what you will never find is a lilst of all printers, APRINTERS() only will list a) local and b) known network printers. Choice is important, but in a larger corporation you will NOT list all printers, you'll avoid that. Even when you find 100 A4 printers, which one do you choose, whichj one is not only near in network hops terms, but within the same office or building of the user? You can't decide that, so LET THE USER CHOOSE THIS.

Here trying to make your software smart is just being a smartass. Who'll pay you for writing a masterpiece of a software finding a nearby A4 printer, if all you need to do is ask the user for his printer? Keep it simple.

Bye, Olaf.

 

[Rajesh Karunakaran]

Hi Olaf,

It's a pleasure to read you again!
Yes, I completely agree with your views/advices/concepts. Thank you!

Just want to tell you too what I am thinking.

I have already a feature for printer redirections for some reports and documents (eg. invoices, cash receipts etc). These settings I am saving in a table. So, I set the printer to the one specified in this table if an entry is available. Otherwise, I just let the report use the Windows default (obviously). So, I thought of creating a provision for mentioning the "printer to be used for report preview" too in the same module so that the user (or me or the person installs the software) can select and save any printer which is A4 or above to be the base for report previews. So whenever I run a report I would look for this setting and if available I would set that printer, run the report and reset the printer setting back to the one it was (of course I would do this only if an exclusive printer specification is NOT AVAILABLE for this report in the Printer Re-Direction table).

I believe, this way I can control and maintain this.
Just thought my method may be useful to others also.

Thank you team!
Rajesh

 

[Olaf Doschke]

Thats fine, actually also part of what I said

ask him once and store as config

In a larger corporation I let this be a local setting stored in an ini in the local all users profile, then a local user specific ini may override that. There is no global default, as the nearest by local printer can't be the same, but when that's the case a central config data table always is a nice option, also for other settings like paths. Let the path to this global config be the only knowledge necessary locally to know where to look for further config information. The big advantage is you have global info in one place, easier to administrate, both for you or customers IT department.

Other possibilities for such specific print outs as slips are embedding the slip printer info into receipt reports. While embedding printer info is mostly considered bad for normal reports, the slip receipt report is a very printer specific report, so it makes sense, it only doesn't make sense, if that can't be set up as a local printer always having the same name for each POS station, then it get's a bit questionable to modify one master frx to different local pos printers. Of course you wouldn't want all stations to print out receipts only at one register.

You may also print with very low level printing directly to a COM interface or using OPOS, as I just recently learned, then that would not be about the usual reports and windows printers at all.

Bye, Olaf.

 

[Mike Lewis]

Hi Rajesh,

As Olaf says, the usual way of doing this is to let the user select the printer, which you do by GETPRINTER(). It is the user who knows which printers are available and what size paper is loaded into them.

However, I can see that your requirements go beyond that. A solution would be to call APRINTERS() to determine which printers are available, then to call PRTINFO() for each printer in turn, passing 2 (= paper size) as the second parameter. The function will return 9 if the printer is set for A4. You will then choose one of the relevant printers for your report, using SET PRINTER TO.

One point to watch is that PRTINFO() will tell you that the printer is set to print on A4. But I'm not sure if that necessarily means that A4 paper is actually loaded into it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Hi Mike,
Thank you! Yes, I am thinking on the same line as you and others.

I typically use a module similar to the one in he pic.

In this one, I would add a setting for 'Printer for general report previewing' or something like that also.

By the way, A4 was just an example (sorry if I confused you) as usually almost all reports are A4 based, either portrait or landscape.
It could have been any other printer which can accommodate paper sizes as bigger as A4 or above. The only thing is that, the program should know which printer to set to before opening the preview. Of course, if the user specifies a wrong printer for that settings, the preview also won't be proper, just like the problems with any other user definable setups.

It's a pleasure to participate in discussions like this in this forum.
Thank you very much for your time!

Rajesh

 

[Olaf Doschke]

>The only thing is that, the program should know which printer to set to before opening the preview. Of course, if the user specifies a wrong printer for that settings, the preview also won't be proper, just like the problems with any other user definable setups.

That problem is a minor problem, as the user will see and adapt. It's obvious he made a wrong choice. If software tries to be smart users a) won't notice and be thankful for that intelligence as long as it works, but b) if making restrictions on false asssumptions for what printer to allow, will easily make it too restrictive, so that hurts more, than it helps.

In the end also hardware products have their limitation to let the user not do anything wrongly. Even a lamp holder can only limit you to use a light bulb with matching thread (sorr if using wrong terminology here, I just looked up that vocabulary), but you still can use bulbs with wrong wattage. So there is a responsibility of the user, too. And in this case it's quite easy to make another pick. I've seen no place, printers won't get labelled with their network name, queue name or other windows printer name, so you know the printer itself you know what to pick.

But yes, it would be another good choice to save that choice in your configuration of printers and give it a user friendly name like you have there, already.

Bye, Olaf.

 

[Mike Lewis]

The only thing is that, the program should know which printer to set to before opening the preview. Of course, if the user specifies a wrong printer for that settings, the preview also won't be proper, just like the problems with any other user definable setups.

Yes, I see your point.

Another approach might be to let the user change the printer during the preview. They would still use the form you showed to make an initial choice of printer. You would then display the preview. But the preview window would also have a drop-down control which lets them change the printer, with the preview being updated straight away to reflect the new choice. That way, it wouldn't matter if they made a mistake with their intial choice, and they would be able to easily determine which is the correct printer.

This is not as impossible as it might sound. In thread184-1774651, we discussed creating your own report preview form, which you invoke with the IN WINDOW clause in the REPORT FORM command. (Don't bother to read the entire thread, which currently has 69 posts; the first few posts are the relevant ones.)

Or you can customise a report listener to do the job (but only in VFP 9.0). For a summary of the steps involved in doing that, see

http://www.ml-consult.co.uk/foxst-46.htm.

This approach might not suit you, but it might be worth considering.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Thank you Mike for the suggestions. I will go through that for sure!

Rajesh

 

[Olaf Doschke]

I never did, but you can also customize the normal print preview toolbar, so that printer choice could be added into that:

http://fox.wikis.com/wc.dll?Wiki~HidethePrintButtonfromthePrintPreviewToolbar

This tells about hiding the print button, so you have a pure preview only, but it also explains how to customize that native toolbar more generally, how to get into its customization mode.

Besides that in the lengthy thread mostly between me and ameedoo we finally discussed FoxyPreviewer modifications. FoxyPreviewer goes a much more complete approach available for VFP9 by replacing the default reportpreview.app of VFP9 with a whole new implementation. Within that new app module, the FoxyPreviwer developers could not only redesign the preview window, they also simply did their own toolbar and within that they even allow redirecting the preview into xls, pdf or word.

I would even keep it simpler in this case, users can close the preview, select the correct printer and restart print preview. Especially since your printer configuration places technical printer choices in named configuration items, you can also offer a custom GETPRINTER dialog letting them choose from your known and preset invoce/receipt/credit note printer settings without needing to know the details configured in them. And if that settings are wrongly configured, that is just a second level problem, as you only need to set this correct once in the typical lifetime of a register, maybe several further times, if the POS printer needed an replacement and again if usual letter/A4 printers change.

And still - while such a choice is user friendlier, you overestimate the complexity you want to hide in comparison with GETPRINTER, in the first place its only local printers anyway, so there is no big need for a simpler dialog. In the end any technical personal may make a first setup, though it's nothing so special needing an expert. Windows itself and Word also offer nothing much better than what VFP offers with GETPRINTER().

If you restrict too much and on false assumptions, users can't correct this. And that doesn't mean an administrator failed to make the initial printer choices or installed printer drivers wrongly or with non speaking names - by the way, that point of printer driver setup is where you can let a printer have a user friendlier name already, you don't need to name your printer just with the technical name of the vendor, you can call it slip printer and document printer on that low level already. In the end the admin might have totally correctly set this up at the time of installation, but things can change over a long time. And if admins are not available and end users get no choice but preconfigured known names, they will be lost with too few options they can't correct. That's exactly what happens with such thoughts about keeping users off of seemingly too low level settings to make. If only admins can make certain settings, that's what I said earlier, is what will hurt more, than it helps. A good design here is to allow easy config and if that doesn't help, offer more detailed setup. Windows showcases this with many dialogs having an extended or advanced mode.

So finally there is no problem of what to offer users and where to put the balance of intelligence and preventing harm. You don't need to choose between allowing the user a low level choice or giving him the most proper choices intelligently. You can offer the intelligent choice and allow further choices in advanced mode, taking into account you are only providing your own code, not yourself. It's neither you nor your software failing, if it can't automatically find the correct printer. And your software also doesn't shine with such a feature, as it's a not hard and once only task most of the time anyway. Software shines with intelligent features within the major work flows users do most frequent, so for example how fast slips print will be more important, how nice they look, how good they are layouted...

Let me end in a real life comparison once more. In first aid you may be confronted with a task only a real doctor could really do, eg reanimation. If you ever visited a course on first aid you get taught that you for example better try a reanimation of a non breathing crash victim than wait for a doctor having learned it better. A novice trying can be better here than a non present doctor. In the same sense don't restrict users to not be able to do administrative takss of your softwar configuration themselves - I am not talking of real administrative tasks here, that of course can give them too much powers. Choosing the correct printer is really something you can do with trial and error not at all harmful. Most dangerous harm is waste of thermal printer paper and/or ribbon.

Bye, Olaf.

 

[robertjones4849]

there are few ways to set your desired printer as default,

1. Go to controle panel
2. open printer and fax
3. Richt click desired printer
4. From the opened menu now selet defailt printer

 

[Mike Gagnon]

This thread is 4 months old.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Mike Lewis]

Not only is the thread four months old, but the question is concerned with programmatic printer settings. I think we can assume that everyone here knows how to set the default printer in Windows.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads