# Base: Page header/footer not generated [closed]

LO 5.3.7.2.0 from Fedora 26 distro, Linux 4.13

Using Base report generator to issue a summary of the underlying DB in Writer format. Header/footer used:

• Page: expected to repeat on every page, but nothing printed
• Report: inserts elements once before details and once after; not used in this case but works fine
• Detail: used for "group" insertions before and after the section iterating on DB records

I came upon this question on LO site, but suggested fix is not available. In my LO version, Format->Page only offers Page and Background tabs, no Header nor Footer.

Temporarily, I'm using detail header/footer as surrogates since I force a page break between groups but result is not nice looking because some information I've inserted in detail footer should be printed in a fixed location at bottom of page (page footer) instead of floating in the page, depending on the number of detail lines.

How can I make page header/footer print where they belong?

UPDATE 2018-12-3

After @Ratslinger's comment, I get the page header/footer. For readers: please note the fix must be applied on Writer generated document not on the report template in Base.

Supplementary question: the workaround needs a manual step (according to my skills) in the generated document which breaks the automated production chain. How can the fix be automatically be applied with a script?

edit retag reopen merge delete

### Closed for the following reason the question is answered, right answer was accepted by ajlittoz close date 2017-12-05 17:53:21.655850

@ajlittoz - I don't see this problem in TDF LO v5.4.3.2 (or even previous versions). Again, possible distro version problem? Have again tested & page header/footer repeat on every page. BTW - Format->Page mentioned on link refers to the output document and not in the report edit.

( 2017-12-02 23:31:55 +0200 )edit

Thanks for the precision. See question update.

Otherwise, same behaviour with LO 5.4.3.2 under Fedora 27 I'll try to check with an LO version.

( 2017-12-03 10:49:00 +0200 )edit

Sort by » oldest newest most voted

Hello @ajlittoz,

This is in answer to your request for an automated script. Well, again Report Builder is not without its' problems or I am just missing something. But at this point what I have works with its' own limitations.

As you know, Report Builder outputs a Writer document in Read Only status. The setting you need to change is in the Writer document and I don't see a way to access it before creation. So in order to have a macro change the necessary settings, the Writer document must be opened. Kind of a catch 22. The solution I came up with is to actually open the report within the macro and then the changes could be made. This means you need to run the macro via a button on a form or even an item on the toolbar or menu and thus generate the report.

Sub SetHeaderAutofit
Dim ocontroller As Object
Dim document As Object
Dim dispatcher As Object
Dim oDoc As Object
Dim oStyleFamilies As Object
Dim oPage As Object
Dim oStandard As Object
ocontroller = Thisdatabasedocument.currentController
if not ocontroller.isconnected then ocontroller.connect
oDoc = Thisdatabasedocument.reportdocuments.getbyname("YOUR_REPORT_NAME").open
document   = oDoc.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
dispatcher.executeDispatch(document, ".uno:EditDoc", "", 0, Array()) 'Turn off edit mode'
oStyleFamilies = oDoc.getStyleFamilies()
oPage = oStyleFamilies.getByName("PageStyles")
oStandard = oPage.getByName("Standard")
oStandard.HeaderIsDynamicHeight = True     'Sets AutoFit height'
oStandard.FooterIsDynamicHeight = True      'Sets AutoFit height'
oDoc.setModified(0)        'Above settings set document to modified so this turns it off'
End Sub


Now I don't have this problem on my system so I am not positive it does what you need. I do know it sets AutoFit height correctly.

Edit 12/04/2017:

Almost gave up on this but have a working model for your automated process. You just need to finish the way you want. First, because of automating, the code in the macro must change:

Option Explicit
Dim oContext As Object
Dim oRegistered As Object
Dim dbForms As Object
Dim oAConnection As Object
Dim document As Object
Dim dispatcher As Object
Dim oDoc As Object
Dim oStyleFamilies As Object
Dim oPage As Object
Dim oStandard As Object
Dim sReportName As String
oContext = CreateUnoService("com.sun.star.sdb.DatabaseContext")
oRegistered = oContext.getRegisteredObject("REGISTERED_DATABASE_NAME_HERE")
dbForms = oRegistered.DatabaseDocument.ReportDocuments
oAConnection = oRegistered.getConnection("","")
Dim pProp(1) As New com.sun.star.beans.PropertyValue
pProp(0).Name = "ActiveConnection"
pProp(0).Value = oAConnection
pProp(1).Name = "OpenMode"
pProp(1).Value = "open"
sReportName = "REPORT_NAME_HERE"
oDoc = dbForms.loadComponentFromURL(sReportName, "_blank", 8, pProp())
document   = oDoc.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
dispatcher.executeDispatch(document, ".uno:EditDoc", "", 0, Array())
oStyleFamilies = oDoc.getStyleFamilies()
oPage = oStyleFamilies.getByName("PageStyles")
oStandard = oPage.getByName("Standard")
oStandard.FooterIsDynamicHeight = True
oDoc.setModified(0)
End Sub


You will notice you need to register the database and use the name in the code. You also need to fill in your report name. Another difference is this macro now needs to go in "My Macros.Standard ...

more

@Ratslinger: Sorry for slow answer, quite busy today. Errors on line ocontroller= … (object variable not set). Tried to change declaration Dim Thisdatabasedocument … without success. Is Thisdatabasedocument a predefined var? Otherwise, it is indeed not set.

( 2017-12-04 16:48:09 +0200 )edit

Don't worry about response time. I have some which go days, weeks & even months! As I have tested this, my initial reaction is it is a matter of where you placed the macro. It should be in the .odb and not MyMacros. This would account for the problem.

( 2017-12-04 16:53:29 +0200 )edit

Also, if you leave the macro in MyMacros, change Thisdatabasedocument (occurs twice in code) to ThisComponent.Parent. That will correct the situation. It is a matter of where the macro resides as to how you access ThisDatabaseDocument.

( 2017-12-04 17:03:32 +0200 )edit

@Ratslinger: with correct location, works like a charm! Thanks a lot. +1

Next step is full automation. I don't know if it is possible to launch report generation and patching (i.e. macro execution) from a shell script.

( 2017-12-04 17:29:41 +0200 )edit

Wow! You really master macros. I'd +1 once more but possibility already used.

There's only a little glitch: if I run the shell script without opening .odb first, I get a loadful of trace, apparently related to CSSParserInstantiationException (not familiar with macros, so I can't interpret it). Despite the trace, it works allright.

( 2017-12-05 10:42:02 +0200 )edit

Yeah. That is from Pentaho (report engine used) compiling the code for the report. Don't think I can eliminate it. Frankly, I'm happy just to be able to run a Base report without opening an .odb. Had to piece that one together from multiple projects. If I figure a way, time permitting, I'll post.

( 2017-12-05 14:52:12 +0200 )edit

Don't bother for a fix. It works and I'll be the only one in charge of reports. All others only interact with the DB through a web browser, so they don't see the internals.

Once again, many thanks.

( 2017-12-05 17:52:56 +0200 )edit

OK! Not sure about time anyway. Glad you have what you want/need. Thanks for closing this out.

( 2017-12-05 18:33:49 +0200 )edit