REPORT FORM ... TO PRINTER

[EinTerraner]

good... whatever your timezone is

I've no Idea what i did wrong. but since 15 Years it worked well for me.

1st Step i prepare two Cursors named "DRU_KOPF" and "DRU_DATA".
DRU_KOPF has only one record and it contains directives and basic informations for my report like report Title-, Header- and Footer-sections.
DRU_DATA is filled with all data used in several Detail-sections. Also some boolean fields for the "Print when"-clause
But now there is a strange beahvior and a difference between the PREVIEW and TO PRINTER

...
&&creating DRU_DATA
     SELECT * FROM (SourceData) INTO CURSOR DRU_DATA WHERE ...
     SELECT DRU_DATA
     SELETE TAG ALL
     ALTER TABLE DRU_DATA ADD ..... && add some directives for the report
     ....
&&creating ReportFile Lc_Dest
     Lc_Dest = <function for the desired FRX-File>
&&select printername Lc_Port
SET PRINTER TO NAME (Lc_Port)

select DRU_DATA
go top
if Tf_View       && preview this document
    SET CLASSLIB TO (ThisForm.ClassLibrary) ADDITIVE
    Lo_Form = NEWOBJECT("_defobject_form")
    WITH Lo_Form
        .TitleBar = 1
        .BorderStyle = 3
        .height = SYSMETRIC(22)
        .width = (.Height/6)*5
        .autocenter = .t.
        .name = GETWORDNUM(ThisForm.Name, 1, "ß")+"_"+This.Name
        .alwaysontop = .t.
        .closable = .T.
        .ControlBox = .T.
        .MaxButton = .f.
        .MinButton = .f.
        .Themes = .t.
        .Caption = ALLTRIM(Lc_Name)
        .Show(1)
        SELECT Dru_Data
        REPORT FORM (Lc_Dest) PREVIEW WINDOW (.Name)
        .WindowState = 0
        .release()
    ENDWITH

else             && print this document
    IF ReportNoPrompt
        REPORT FORM (Lc_Dest) TO PRINTER NOCONSOLE NOOPTIMIZE
    ELSE
        REPORT FORM (Lc_Dest) TO PRINTER PROMPT NOCONSOLE
    ENDIF

endif

with PREVIEW it works well and i'll get the correct amount of pages like this snippet to see

but the TO PRINTER output generates something between 50 and 80 pages and they look like this snippet

it only prints the 1st Line from my DRU_DATA file cpl hundred times.

the ridiculous part now:
if i add a line like tzhe BROWSE

    SET ORDER TO DRU_BELG IN Dru_Data
    GO TOP IN Dru_Data
    SELECT (Dru_Data
BROWSE LAST FIELDS DISLINE, ARTKURZ, ARTMENG, ARTVKPR, ARTGSUM

or a INKEY(1)

    SET ORDER TO DRU_BELG IN Dru_Data
    GO TOP IN Dru_Data)
    SELECT Dru_Data
=INKEY(1)

The TO PRINTER output is correct

IT DRIVES ME CRAZY

 

[ManniB]

EinTerraner, I don't think that's true. If you click on a command button it gets focus (you see a gray frame on the button), but if you click on an image afterwards, the frame on the command button remains. So a click on an image does not automatically change the focus.

 

[EinTerraner]

EinTerraner, I don't think that's true.

OOPS. I'm really sorry about this false statement. 4GIVE ME I've forgotten my FakeButton has some code (DODEFAULT()) in the Click-Event and there i set the focus back to my last editable object in the form
This is a edit-gimmick in my forms since i run Fox (6) so i dnt loose my last editobject by pressing some checkboxes or whatever

 

[ManniB]

I see, so you took care of the focus yourself.
But most importantly you found a solution to your problem with that extra form

 

[EinTerraner]

I see, so you took care of the focus yourself.
But most importantly you found a solution to your problem with that extra form

As above mentioned. I never use the real sourcedata to juggle around. Allways use a copy with own cursor for manipulate the data.

Yes, i got (but not really common and clean used) a solution / workaround with my REPORT FORM... blalbla

 

[Chris Miller]

Yes, that's true, Manni. And you also gave the usual typical construct that hides this effect. Using a print button the button will get focus. So what's "dangerous" is printing from a grid method or a control within the grid - also a button, when a grid cell has focus, that's still letting the grid have focus, not just the textbox of the grid cell.

It's surely also in part the reason it wasn't discovered. Though it is known for very long, it never got fixed with a later VFP version or SP or Hotfix. It had become "by design" with a well known workaraound. In the same sense some well known bugs were never fixed when there is a well known workaround. Also in VFP9 SP2 or the last Hotfixes.

 

[Chris Miller]

There's another solution and good advice to go about bulk reports, no matter if they get actually printed or you generatee a batch of PDFs for mail attachments: Do batch processing in a separate process, i.e. a dedicated exe for this. That wouldn't need a user interface at all, just the data to get going. And it would make this batch processing a background process not disturbing the rest of the application. You (your users) could go about any other things while the batch processing runs.

Any bulk processing usually is not involving user interation, as you made a point yourself, already, you wouldn't want to click print tens, hundreds or even thousands of times, so generally there is only the case of errors needing to be addressed to continue or such unusual interventions by a user, in the best case you have prepared all data to let the batch run succeed without any further ado. And things like errors could also be logged to be addressed later, i.e. a smaller batch run of failed addressees or whatever.