Printing from Preview shows awkward behaviors

[Rajesh Karunakaran]

Hi Team,

I have a very strange problem!

My report preview is okay.
The print also is okay if printed independently.
But, if I print directly from the report preview, it shows wrong data and awkward behaviors.
Sometimes it reports all records instead of specific ones.

In the INIT of report from, I am creating the cursor combining data from various tables. At the last of INIT section, I am selecting my report source cursor. But when I SET STEP ON I see that the current alias is still another table. When I select my cursor once again form the debug session, then the ALIAS() shows correct cursor name. I think, the alias selection problem, when we use the direct print causing the issue. (I have attached a picture showing this behavior)

I have read here itself that if the form has a grid and the focus is still on it, there are chances that the grid will steal the ALIAS() control and hence the currently selected alias may change. So, I am setting my focus to a temporary button before launching the preview. But still the problem persists.

Anyone has any idea?
How can I solve this?

Rajesh

 

[Mike Lewis]

Rajesh,

This is a known problem. And you are right that it is connected to the grid "stealing" the alias. The normal solution is to temporarily set focus away from the grid before launching the preview. But you say you have tried that, and it doesn't work. Are you sure the focus is on the other control at the time that you issue the REPORT FORM?

Another solution would be to disabe the grid, then do REPORT FORM, and then re-enable the grid.

Here is some more information:

http://hexcentral.blogspot.com/2012/04/vfp-reports-not-showing-same-data-as.html#more

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Mike,

I tried both setting the focus to a temporary command button and disabling the grid.
It doesn't help.

Working on this. Will update you as soon as I get something on this.

Hope all in your family doing fine.

Thanks
Rajesh

 

[Rajesh Karunakaran]

Hi Mike,

I think, this behavior is not the same way for each and everyone.
I believe, your suggestion which worked for yourself or other persons doesn't work for me.
So, it has certainly connection to the data we use & create for report form.
But, everything I use are just basics and what I expect is very much obvious vfp native way.
Unfortunately it differs!

Will highly appreciate views from our other friends as well.

Thank you for your time.
Rajesh

 

[Rajesh Karunakaran]

Hi Mike,

The problem very much appears to be solved.
My boss asked me to insert the below line before the actual PREVIEW command.
i.e., my code will be as follows

lTmpRepOut = FORCEEXT(SYS(3) + SYS(3), 'TXT')
REPORT FORM (pReportFile) TO FILE (lTmpRepOut) NOCONSOLE SUMMARY

after this the actual PREVIEW command

REPORT FORM (pReportFile) PREVIEW NOCONSOLE

And at last I am erasing the temporary file created using

IF FILE(lTmpRepOut)
    ERASE &lTmpRepOut
ENDIF

I am not sure about what's happening in the background.
It seems, the initial run through of the report form set the environment that the next preview gets it right.

I thought I should share the solution I got!

Thanks
Rajesh

 

[Rajesh Karunakaran]

Hi Mike,

In fact, I have combined the above additional command line
with the focus relocating and grid deactivating commands that you suggested.

However, I have observed one thing. In a Win 7 pc, I have default printer as a PDF printer.
There when I run this, at the '..TO FILE...' line, instead of the output goes to a file,
I am getting the PDF printer's dialog. However, in my Win 10 64, it just sends the output to a TXT file.
I am not sure why. I believe, I have exactly the same code in both cases.

Thanks,
Rajesh

 

[Mike Lewis]

Rajesh,

Sorry but I can't see anything else that would explain the behaviour you are seeing.

Regarding REPORT FORM ... TO FILE, I believe there was some change relevant to this between VFP 8 and 9. Unfortunately, I don't have a note of the details. You could check the setting of REPORTBEHAVIOR. If it is 90, try changing it to 80, and vice versa. Also, you might need to add the keyword ASCII to the TO FILE clause, otherwise you might get printer control codes in the file, which might cause unwanted effects.

Im not sure about any of this, and in any case it doesn't explain your original problem.

The only other thing I can suggest is that you separate out the various problems. Start by temporarily completely removing the TO FILE output, and focus on the problem of the printed report being different from the preview. Also, if the behaviour is different between Windows 7 and Windows 10, check if there are any differences in your code in these two versions.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Hi Mike,
I think I have not explained it well enough.

I am referring to the same original problem only. The 'REPORT FORM.....TO FILE output NOCONSOLE' line
was added only as a resort to solve the original problem and I am not using it for my preview or print.
So, as I don't need that output.txt file for anything, the ASCII clause may not be of any difference in this case (isn't it?).
The preview is achieved by the next line (which was originally there) 'REPORT FORM....PREVIEW'.
So, after inserting that '....TO FILE output NOCONSOLE' line before the original REPORT FORM line, the problem of getting
errors in direct print from preview appears to be solved.

But now, that 'REPORT FORM.....TO FILE output NOCONSOLE' line produces another problem.
From that line, generally we expect it just to create a txt file without showing anything on screen.
Now, it is okay in my Win 10 pc, but it pops up my PDF printer dialog in Win 7.

As you suggested let me check each and everything once again in both PCs,
say, the code, the default printer setup, the printer environment etc.

Rajesh

 

[mjcmkrsr]

hi

Now, it is okay in my Win 10 pc, but it pops up my PDF printer dialog in Win 7.

This has nothing to do with Windows - your PDF print driver probably has a setting item : "Open the document after creation Yes/No/Ask the user". At least mine does.

hth

MarK

 

[Mike Lewis]

generally we expect it just to create a txt file without showing anything on screen.
Now, it is okay in my Win 10 pc, but it pops up my PDF printer dialog in Win 7.

So, what you are seeing on the screen is not the report itself, but a PDF dialog. I hadn't realised that.

This is what I would expect. If you omit the keyword ASCII from the TO FILE clause, VFP will send an image of the report to the text file, complete with control codes, etc. If the default printer is a PDF printer, it has to know the destination filename, hence the dialogue. That doesn't apply if the default printer is a physical printer.

So it looks likely that, on your Windows 7 machine, the default printer is PDF driver, but on your Windows 10 system it is a physical printer. That would explain why you are seeing the dialogue when you do.

None of this has got anything to do with your original problem. It is just serving as a distraction.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[mjcmkrsr]

Hi,

You may also want NOT to save the Printer Environment in your report forms: Report Designer - RightClick - Properties - Uncheck "Save printer environment" and allow the user to choose the printer e.g.

Report Form repMyReport Noconsole to Printer Prompt

hth

MarK

 

[Mike Lewis]

A small clarification to my previous post, I have observed the following behaviour:

If the default printer is a PDF driver (PDF Complete, in my case):

- REPORT FORM .. TO FILE always prints to a PDF; a text file is created, but is always empty;

- With PDF Complete, I see the File dialogue, but this would depend on settings within the driver;

- Adding ASCII to the command makes no difference to the above.

If the default printer is a physical printer (an HP Laserjet in my case):

- REPORT FORM ... TO FILE creates a binary file, containing printer control codes and very little recognisable text;

- REPORT FORM ... TO FILE ASCII creates a text file containing just the data from the report, with no formatting of any kind.

The binary file mentioned above is presumably in a form that can be dumped to the relevant physical printer to output the hard-copy report. You would do that with the DOS COPY command, or printing in Windows using a text-only printer driver (do such things still exist?). This would have been useful back in the day when a given computer might not have had immediate access to a printer.

As I mentioned earlier, none of this has any relevance to the original problem, but I hope somebody might find it of minor interest.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

I wonder if the REPORT FORM ... TO FILE is just inserting a delay and if that's what's solving the original problem. Try using the API Sleep function before your REPORT FORM command instead and see if that resolves the original issue.

Tamar

 

[TamarGranor]

Also meant to say you might try moving the code to build the report cursor out of the report itself and into something else (a method of the form that's running?) and see if that makes a difference.

Tamar

 

[Rajesh Karunakaran]

Hi All,

Sorry for my silence for 2 days.

The problem has not actually been solved even though it appeared so. Adding the TO FILE line in additional to the original TO PREVIEW line seemed to solve the problem in my PC. But, in client's side it's the same. Now, we almost figured out that the printer driver does something in background which disturbs the Selected Alias (the first pic I had posted). Anyway, we already have a 'Print?' dialog outside of preview in all reports which is perfect (but the client wanted to print from the preview itself!). So, temporarily this stands managed.

Mike,
Yes, the behavior when the default printer is a PDF is almost similar to what you mentioned, obvious reason for getting a dialog on the TO FILE line.

Tamar,
Rather than a delay, the TO FILE line helps in a report run through before the actual TO PREVIEW line which somehow appeared to solve the problem. But later I realised it doesn't solve in all cases.

I also was thinking taking the code from INIT (of FRX) to the form. Even though I didn't try it, I believe, that must solve the problem.

Thank you all,
Rajesh