Curious Problem with Margins in Inherited Reports

Polomint

An obscure problem arose in our application, where the top and bottom margins were "reversed" on printed reports when laid out in Landscape format.

The set-up is quite complex, so it seemed sensible to build a minimal test application and try to eliminate factors until the root cause could be found.

The main points of the set-up are:
- the FastReport with the "wrong" margins inherits its definition from a Portrait template, changing only the Orientation to Landscape, and the text in the Report Header
- both of the Template and Descendant reports are defined in self-contained Units with their own TfrxReport component, the Descendant Unit / Form inherits its design from the Template Unit / Form

The above constraints emulate the architecture of our application and work well for keeping common stuff in one place, and "encapsulating" our Reports.

The Application and the Test Project both use FastReport Vcl Pro 5.6.4, and are built with Delphi and tested with both RAD Studio XE7 and Seattle.

The Test Project just fires off the FR Preview Form for the appropriate report when one of the buttons is clicked. We've dropped frxPDFexport component on the Main Form to allow the Previews to "dump" the result to a file.

Polomint

FR Version 5.6.6 (released yesterday) has been installed and tested. Sadly it does not fix the problem. [img]style_emoticons/<#EMO_DIR#>/sad.gif" style="vertical-align:middle" emoid=":(" border="0" alt="sad.gif" /> Oh and the problem is not limited to "inherited reports". A single report which is set up as Portrait** which is flipped programmatically by setting Orientation to poLandscape shows the same symptoms. ** with one or more different margins.[/img]

Polomint

Still an issue in v5.6.8 [img]style_emoticons/<#EMO_DIR#>/sad.gif" style="vertical-align:middle" emoid=":(" border="0" alt="sad.gif" /> ====== Update ====== I've bitten the bullet and reviewed the source (for FRv5). Looks like our problem is caused by the Set Method for the Orientation property of TfrxReportPage (in frxClass.pas). When Orientation changes, the codes swaps the PageHeight and PageWidth (as you would expect), but for some reason the code also changes the Margin values: if changing Portrait => Landscape (our situation) - LeftMargin := old TopMargin - RightMargin := old BottomMargin - TopMargin := old RightMargin - BottomMargin := old LeftMargin if changing Landscape => Portrait - LeftMargin := oldBottomMargin - RightMargin := old TopMargin - TopMargin := old LeftMargin - BottomMargin := old RightMargin[/img]

procedure TfrxReportPage.SetOrientation(Value: TPrinterOrientation);
var
  e, m1, m2, m3, m4: Extended;
begin
  if FOrientation <> Value then
  begin
    e := FPaperWidth;
    FPaperWidth := FPaperHeight;
    FPaperHeight := e;

    m1 := FLeftMargin;
    m2 := FRightMargin;
    m3 := FTopMargin;
    m4 := FBottomMargin;

    if Value = poLandscape then
    begin
      FLeftMargin := m3;
      FRightMargin := m4;
      FTopMargin := m2;
      FBottomMargin := m1;
    end
    else
    begin
      FLeftMargin := m4;
      FRightMargin := m3;
      FTopMargin := m1;
      FBottomMargin := m2;
    end;
    UpdateDimensions;
  end;

  FOrientation := Value;
end;

I can't think of a situation where this latter outcome would be useful. It seems to me that TopMargin is always the dimension of the edge above the top of the page's text, and contrariwise for the other three.

Does anyone rely on this behaviour? It looks wrong to me.

I'd like to hear the views of other FastReport v5/v6 licensees.

Meanwhile we have two options going forward:
- Zap the SetOrientation method to disable this behaviour (but will have to do it for every new version of FR installed!)
- Create a helper procedure in our FastReport Common Functions Unit, to set Orientation, saving Margins before and restoring after calling the native code

The latter is probably the more stable alternative, but produces more obscure Application Code...

Cheers, Paul

Polomint

Still an issue in v6.0.13

Polomint

No further forward in v6.1.6 sadly.