Base: Page header/footer not generated

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, FormatPage 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?

@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.

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.

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
Sub SetHeaderAutofit
    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.HeaderIsDynamicHeight = True
	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.Module1”. This is because of the execution and the fact the .odb isn’t really open (something to access ThisDatabaseDocument or ThisComponent).

Now the only thing remaining is the actual running. With the above set as stated this works for me in terminal (Mint 18.3):

libreoffice5.4  "macro:///Standard.Module1.SetHeaderAutofit"

That will start LO and run the macro which in turn runs the report with correct Autofit settings. :slight_smile:

@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.

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.

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.

@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.

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.

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.

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.

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