Can no longer set the printers - VFP9 1

[davisonpro]

Hello,

I recently built my VFP7 app using VFP9 but I have not really begun the full migration project.

I can select the correct printer when using PROMPT but nothing seems to be able to "overcome" the Windows default printer when it comes to issuing my SET PRINTER commands. I've done hours and days of research and tried everything I've found in this forum and all the others. I've hacked and stripped and checked and it's not an FRX issue.

My app allows users to set a default printer to use with my app - well, it used to. It was all super simple code that always worked with no issues.

I've used all the NAME GETPRINTER() and APRINTER() and every other piece of trick code I can find - it all runs just fine EXCEPT that the reports always go to the Windows default printer no matter what I do.

Any other ideas?

 

[Mike Lewis]

Just to eliminate one more possibility, have you tried this:

1. Open the report in the report designer.

2. In the Report menu, make sure there is no tick against Printer Environment.

3. Save the report.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[davisonpro]

Thank you Mike.

I've already done that. In fact, I've read all of your articles and tried every tip you have posted. I've also read every article by Olaf and Mike Gannon and have been through all of those tips, tricks, hacks, strips, etc.

I know it's not the "save environment" thing because none of these reports were created using any printer that I currently own. Also, if I go into my Windows Control Panel and change my Windows default printer, all the reports will then go to that printer every time. Again, none of these reports were ever built using any of those printers, either.

Since I'm chaining a series of reports, I must use the "REPORT FORM xxxx TO PRINTER" so I can't use the "PROMPT" clause or the "NAME GETPRINTER()" with them - although the "PROMPT" works just fine when printing a single report.

I'm seriously considering trying to add an API call to change the Windows default printer but my users will not be very happy with that option as they are already using that as a "work around" while they wait for me to fix this issue.

It's quite strange and seems to be worse with Win7 since the VFP7 version can't seem to overcome the Win7 default printer settings either.

BTW: my REPORT BEHAVIOR setting is still "80" since the "90" settings just blew up my reports as they haven't been edited using the VFP9 Report Writer yet.

Any other ideas?

 

[Mike Lewis]

Thank you Mike. ... I've already done that.

Yes, I thought you would have done. I only mentioned it for the sake of completeness.

Since I'm chaining a series of reports, I must use the "REPORT FORM xxxx TO PRINTER" so I can't use the "PROMPT" clause or the "NAME GETPRINTER()" with them - although the "PROMPT" works just fine when printing a single report.

Are you using NOPAGEEJECT to chain the reports? If so, can you not use PROMPT for the first report in the chain? I believe I've done that myself, although I don't have the code handy.

My point is that, if it works with the PROMPT clause, then using PROMPT for the first report in the chain should solve the problem. But presumably you would have tried that as well?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[davisonpro]

Thanks again, Mike!

I went back and commented out all the SET PRINTER stuff and just put the the "PROMPT" on the first of the chained reports - sure enough, the first report went to the printer I selected from "PROMPT" and all the others went to the Windows default printer.

UGH! This is a major annoyance to all of us involved.

Here's the code snippet just in case you want to see:
**** Page 1
SELECT tempmast09
REPORT FORM st3_10page1.frx NOEJECT NOCONSOLE TO PRINTER PROMPT
x = INKEY(1) && EJ - pause 1 second

**** Page 2
SELECT tempdist09
DO CASE
CASE RECCOUNT('tempdist09') < 24
REPORT FORM st3_10page2.frx NOEJECT NOCONSOLE TO PRINTER
OTHERWISE
REPORT FORM st3_10page2.frx NOEJECT NOCONSOLE TO PRINTER
mp1 = 1
ml1 = 23
ml2 = ml1 + 19
DO WHILE mp1 <= m.addtot
COPY TO ARRAY aradds FIELDS jd_name, ;
jd_code, ;
jd_taxable, ;
jd_taxrate, ;
jd_taxamt FOR jd_line > ml1 AND jd_line <= ml2

REPORT FORM st3_09add.frx NOEJECT NOCONSOLE TO PRINTER

mp1 = mp1 + 1
ml1 = ml1 + 19
ml2 = ml2 + 19
ENDDO && mp1 <= m.addtot
ENDCASE

x = INKEY(1) && EJ - pause 1 second

**** Page 3
SELECT tempmast09

REPORT FORM st3_10page3.frx NOEJECT NOCONSOLE TO PRINTER

x = INKEY(1) && EJ - pause 1 second

**** Page 4
SELECT tempmast09
REPORT FORM st3_10pv.frx NOEJECT NOCONSOLE TO PRINTER

**** END

 

[Mike Lewis]

I see you are using NOEJECT. That's not the normal way of chaining reports. In fact, I don't think it does anything in VFP.

What you need is NOPAGEEJECT.

I'm not sure if that will solve the problem, but it must be worth a try.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[GriffMG]

What I do is prompt for the printer BEFORE I run the report, then set that as the default one (within VFP not Windows) and if necessary switch back afterwards...

FUNCTION TMPPRINTER()
	PRIVATE m.PRT_NAME
	m.PRT_NAME = ""
	ON ERROR DO FILEERR
	m.PRT_NAME = GETPRINTER()
	ON ERROR DO USUAL WITH LINENO(),PROGRAM()
	IF !EMPTY(m.PRT_NAME)
		SET PRINTER TO NAME (m.PRT_NAME)
		** DON'T SET THE VARIABLE
		** OR WE'LL HAVE A HEADACHE WHEN THE FILE IS UPDATED
		** IF WE NEED TO KNOW WHAT WAS CHOSEN
		** WE CAN CALL SET("Printer",3) LATER
	ELSE
		KEYBOARD CHR(27)
		INKEY()
	ENDIF
	RETURN(.T.)

I have two error handlers in there FILEERR() always ignores any error and just carries on as usual, whereas USUAL() does report what the problem was before quiting.

I use the tmpprinter() function by calling it from a button on
the form that runs the report - I use SET("Printer",3) to put the name of the currently selected printer in a text box, or as a caption on the form.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[davisonpro]

OMG!

I cannot believe how I missed that! NOEJECT != NOPAGEEJECT

Thank you very much! I'm not done with this but that made a huge difference.

LESSON: when working with code originally developed in FoxPro 2.5...

Al

 

[Mike Lewis]

I'm not done with this but that made a huge difference.

Good.

Are you saying that it solved the problem? If not, I'm curious about what the "huge difference" was <g>.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

In regard to printer selection instead of default printer, what works is SET PRINTER TO NAME (Getprinter()). In previous versions you could use SYS(1037), but that also is limited to Windows Version<6, the system dialog called by SYS(1037) changed in Vista, now it's really just the page setting dialog, without a printer button to set the printer.

SET PRINTER TO NAME (GetPrinter())
and then REPORT FORM ... TO PRINTER

Besides that, the printer must be removed from frxes, in VFP9 that's a checkbox "Save printer environment" in Report properties, Page Layout, and should be set unchecked of course.

The textbox above will always show the default printer, so you know what is saved into the frx, if you check "Save printer environment".

Bye, Olaf.

 

[davisonpro]

Hello Mike - sorry I didn't give a better explanation of the "huge difference" the first time - my phone started ringing as I now have another serious issue with my app.

But, the difference was that the subsequent reports in the chain worked as you said in an earlier post:
PROMPT for the first one - the others started going to the same printer as you stated once I changed NOEJECT to NOPAGEEJECT

Thank you also to Olaf and GriffMG - I can go back and try some of those codes as well (they are almost the same as I started off with) because it may just be that the heart of my issue was failing to notice that there was that NOEJECT which I was looking past because, as a human, I tended to read what I *thought* it said rather than what was actually written.

This is more of that really old, not-very-good code that I bought and it will take me years to bring it up-to-date while continuing to support my customer base.

You are all very kind to me!
Al

 

[Mike Lewis]

Al, delighted that particular problem is solved. Glad to be of help.

We'll leave you now to solve the new serious issue.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy