ReportHeader_Print event not being executed (1 Viewer)

[amorosik]

I'm trying to follow this example, from Karl Donaubauer
At point 8 there is the description of how to 'understand' from code when a report is launched for printing
In itself it is very simple, it intercept the ReportHeader_Print event to know when the report is sent for printing or preview, distinguishing the two things with a previously set flag
I pull down the example code attached to the youtube video, try it and it works exactly as expected
Well I think, now I put the two routines on my report and so I can intercept the report sent to print
I copy the two routines and the module global variable, I start the report, the Report_Activate event starts correctly, the ReportHeader_Print never starts
So I put Karl's example side by side and mine, and I go step by step forward with both
To send to print I use the big button in the ribbon that appears when the report is previewed, and I send to a pdf printer
But on my code the ReportHeader_print event never fires
While on the example code the event starts correctly, so the problem is evidently only on my report
I check the properties of the two reports, which are identical (apart from the data source of mine) and I try again several times but always with negative results
The question is: what is the ReportHeader_Print event inhibited by?
Alternatively, how to understand from the code if a report is sent for printing?

 

[Pat Hartman]

Are you sure you are opening the report in print preview? That is not the default mode for the double-click.

 

[amorosik]

Yes, my report is opened with code:

DoCmd.OpenReport nome_report, Visualizzazione, Nome_Filtro, Condizione_Where, Modalita_Finestra, Argomenti_Apertura

where Visualizzazione is = acViewPreview (=2) verified with debug.print
And on the ribbon bar appear button 'Print', 'Margin', ....

Maybe it could be that the ReportHeader_print event is not executed because on the ReportHeader section there is no text, label, etc...?

 

[The_Doc_Man]

Are you saying that the ReportHeader section is empty? I.e. devoid of any controls at all?

Just as a test, place a line or a tiny rectangle in the section, mark it invisible, and see if that makes it execute your event. OR put in an unbound text box with a height of 1 twip (i.e. just the number 1), again invisible. I'm not going to swear on a stack of Bibles here, but I think Access DOES care as to whether there COULD be something in the section. If you have no controls at all in the section, particularly if the section happens to have "CanShrink" set TRUE, it may have just treated the section as a NoData case. But if you have a report header, that would be a perfect place for a report title line in a label box and that might be enough for a trigger, too.

I've never run across this because I always put labels in my report headers, so an empty report header section just hasn't come up for me. Therefore, I admit I'm guessing at a test that might answer your question.

 

[theDBguy]

Maybe it could be that the ReportHeader_print event is not executed because on the ReportHeader section there is no text, label, etc...?

There was also nothing in the Report Header in the sample db from Karl, but it works.

 

[The_Doc_Man]

OK, I don't know if this is really related to the problem, but... in this link:

Print Event [Access 2003 VBA Language Reference]

learn.microsoft.com

The Print event occurs only for sections that are actually printed. If you need access to data from sections that aren't printed (for example, you are keeping a running sum, but are only printing certain pages), use the Format event instead.

It would appear that print events don't fire in some cases. The "actually printed" condition is what is important here.

On the odd chance that there was a hidden "gotcha" somewhere, I researched PDF printers. Most of them act like device drivers that print to a file rather than to a device, i.e. they act like they are going through a real driver. If they do that, then the "printing" operation looks to Access like a real printer did it. And that means there is no technical loophole regarding whether this is a format-but-don't-print case because of it going to a PDF printer. Access doesn't know it isn't a "real" printer. That means your solution isn't because of the PDF printer. Windows won't know (or won't care) about the difference either. It isn't much, but it narrows down where to look. It has to be something about either that database file or that report or that report section.

 

[amorosik]

Are you saying that the ReportHeader section is empty? I.e. devoid of any controls at all?

Just as a test, place a line or a tiny rectangle in the section, mark it invisible, and see if that makes it execute your event.

Yes, now it works, with a thin line in the Report Header now the event is triggered as I expected
It's very strange because Karl's example is also without anything in the section
Perhaps in my case the HEIGHT of the section was EXACTLY zero, and probably Access treated it as an invisible section

I also tried with nothing in the ReportHeader section and it works the same, the event is executed
And so the problem, in my case, was only the zero height section
And this also explains why Kar's example works, the ReportHeader section height was non-zero

 

[amorosik]

On the odd chance that there was a hidden "gotcha" somewhere

What is a 'gotcha' ?

 

[The_Doc_Man]

Gotcha - American English slang for someone or something that comes at you by surprise and gets you. Originally "got you" but mutated by linguistic drift into "gotcha" because of our tendency to slur some words together. The intermediate form some years ago was "got ya" (substituting Ya for You).

By the way, after the fact it makes sense. A zero-height section can't really be printed and we don't get to see the code by which Access decides what to do with an empty section.