Bug 84185 - - Base - Reportbuilder - Correct Field Location Not Possible for Excel Export
Summary: - Base - Reportbuilder - Correct Field Location Not Possible for Exce...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2014-09-22 13:53 UTC by webdawg
Modified: 2014-10-20 16:09 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description webdawg 2014-09-22 13:53:48 UTC
This is in Arch Linux build-4

I am in the report builder.  I want to export the report as excel in 4 columns.  I cannot as I cannot put the label fields or text boxes right next to each other.  When you build the report through the wizard it lines the fields up just fine.  So if a field is 2.36 length, the next starts with x pos being 2.36.

When I attempt to manually edit the position of the fields or text boxes I get:

This operation is not allowed. The control overlaps with another one.

When, to make it export columns correct be able to align it at the same point or "overlap it" like the wizard does. So columns come out in the spreadsheet document.

When I am manually editing a horizontal line of fields or text boxes I can get the first two to "overlap" or meet with no space in the middle, but after that, no more.
Comment 1 Robert Großkopf 2014-09-24 13:18:07 UTC
Have tested it with OpenSUSE 12.3 64bit rpm Linux and LO Can not confirm the bug. I had positioned 4 textboxes with the mouse and switched the output-format to table-document. Pageheader and pagefooter were set to visible - no.
The only problem I see: I changed the width of one some fields but the with of all fields in the exported document are the same.
Comment 2 webdawg 2014-09-24 13:22:39 UTC
Did you try changing the position to the exact same width of the cell right next to it.


width of first 2.0
x position of second 2.0
width of second 2.0
x position of third 4.0 (this is where it would fail for me)

Comment 3 Robert Großkopf 2014-09-24 14:15:26 UTC
Have first tried it by the mouse without problems.
Now tried it by input of values (here: 2,00 cm - German GUI), also no problem. Set the first field to 0 cm - 2 cm width, the second field to 2 cm, 3 cm width, the third field to 5 cm, 1 cm width and the last field to to 6 cm, 10 cm width.
Then moved the detail-section to the minimum and got a calc-document with all this columns and all the rows.
Could you attach an example?


Comment 4 Alex Thurgood 2014-09-24 16:58:37 UTC
Can not reproduce on OSX, or else I don't understand how to try and reproduce.

1) Drag first field onto report design detail section. Select label and move to desired position.

2) Place field underneath.

3) Repeat for other fields and labels, resizing as required.

The Report Builder creates merged cells, corresponding to the width of the labels, the width of the fields and the height between label and field.

Your problem would no doubt be more easily solved by simply dragging and dropping a query or a table directly onto an empty Calc sheet.
Comment 5 Alex Thurgood 2014-09-24 17:01:44 UTC
Yes, it is a lot more work than the automatic positioning that the wizard carries outm but I see no manual problem with arranging the labels and fields as you wish, tested on LO
Comment 6 Alex Thurgood 2014-09-24 17:11:36 UTC
@webdawg : maybe your Arch version of LO that is the problem ?
Comment 7 Alex Thurgood 2014-09-24 17:18:47 UTC
FWIW, I also tried with three fields and manual entry of widths and heights - no problem positioning the fields one next to another

In Header section:
1st field label x,y : 0,0
2nd field label x,y : 2,0
3rd field label x,y : 4,0
1st, 2nd, 3rd fields organized directly underneath

Reduce Detail and Footer to nothing, execute report, spreadsheet shows field labels in A1,B1 and C1, with data in cells A2, B2 and C2
Comment 8 Alex Thurgood 2014-10-20 16:09:38 UTC
This is reported as working for two different people using two different OSes, closing as worksforme.

If anything, the behaviour seems specific to Arch-provided build