I have designed a report in LibreBase, where two fields shall auto-expand in case there is more content than would fit in the designed bounding-box. When setting the "Auto Grow" attribute of the fields to "Yes", the generation of the report yields the expected result. However, after saving and reopening the reports the attribute is reset to "No" for both fields.
Steps to Reproduce:
2.Design Fields and set attribute "Auto Grow" to "Yes"
4.Reopen Report and check attribute "Auto Grow"
Attribute "Auto Grow" reverts to "No".
Attribute "Auto Grow" should stick to "Yes".
User Profile Reset: No
The generated report of course also doesn't auto grow the fields, so text gets truncated.
Couldn't confirm the buggy behavior. Have tested it with
LO 220.127.116.11 on OpenSUSE 15.1 64bit rpm Linux.
The automatic row height has been added for LO 6.4. So could be the bug has gone since 18.104.22.168. Could you try a newer version?
Created attachment 159487 [details]
Screenshot from report with overflow happening.
The behaviour is still present in LO 22.214.171.124 (which seems to be the latest version for MacOSX). I just installed, set "Auto Grow" to "Yes" and saved the report. After closing the report from edit mode and executing it again, the red triangles indicating overflow are still there.
Created attachment 159488 [details]
Open the report and change label-field "Memo" to Auto Grow → No
Have tested it a little bit more.
When I execute the report while the report is open for editing the auto grow will work.
Then I closed the report-editor and started again and the field won't be set to auto grow.
Then I set the label-field, which is the first field of the row, to auto-grow and the auto-grow will work like it should.
Seems to me the first field in a row had to been set to get the auto grow working while the report isn't opened for editing.
Pleas test the attached database.
Execute the report - all content could be seen.
Edit the report and set the label "Memo" to Auto Grow → No.
Save the report, close the report and start it again.
The fielkd for the content, not only for the label, won't auto grow.
Created attachment 159493 [details]
I took your workaround and applied it to my report. In my report, only the fields "Task Description" and "Task Source" may be larger than the reserved space. The other fields will not ever overflow.
Now however, I set the "Task Number" field (not the label in the header) "Auto Grow" -> "Yes" (also the other fields) and after saving the report, the attribute remains set to "Yes" and the report can be executed any time now, without having to manipulate the arribute "Auto Grow" every single time. So for the time being I am happy.
I still think, it remains a bug. I would like to keep authority on which fields are allowed to "Auto Grow" and which ones not. Now "Task Number" can "Auto Grow" which wouldn't be necessary.
Have changed the title to reflect the problem:
I could chose Auto Grow → Yes for a field while editing a report.
It will work right during the report is opened for editing.
After saving and closing the report it will only work if I had chosen the first field of a row Auto Grow → Yes.
The value for the first field in a row will be saved for all fields of a row while saving the report.
Expected behavior: Value for Auto Grow should be saved for every single element.
Tested with LO 126.96.36.199.2 on OpenSUSE 15.1 64bit rpm Linux.
Actually, I tested to set the first field to "Auto Grow"->"Yes" and left all other fields to "No". After saving and executing the report, the fields set to "No" did overflow with the red triangle shown. Only after setting them to "Yes" and saving (which is then successful to make the "Yes" stick) the report worked as intended.
(In reply to Stephan from comment #6)
> Actually, I tested to set the first field to "Auto Grow"->"Yes" and left all
> other fields to "No". After saving and executing the report, the fields set
> to "No" did overflow with the red triangle shown. Only after setting them to
> "Yes" and saving (which is then successful to make the "Yes" stick) the
> report worked as intended.
Did you test it with the attached database? I tried it again and again. I 'm not able to save "Auto Grow" → "No" for the second field if the first field is set to "Yes". I could execute it right way while opened the Report Builder for editing and will see the red arrows, but when it is saved and closed and I execute the report auto grow will be executed for all fields in the row. Reopened for editing the report and the field I set to "No" is opened with the property "Yes" for "Auto Grow".
If this isn't the bug you have detected I will set this one back to unconfirmed and open a new bug. Seems we have detected different behavior on MAC and Linux system.
The database you provided opens with the "Name" Label and Field "Auto Grow" set to "No". The "Text" and "Memo" Label and Field "Auto Grow" are set to "Yes".
I first changed Text Label and Field to "No", saved and reopened. Both stayed "No". Then I changed Memo Label and Field to "No", saved and reopened. Also those stayed set to "No".
However, when I change one of the Labels to "Yes", the Field automatically inherits the "Yes". When I set the Field to "No" and save, it will not stick. After reopening it will again show "Yes". So it seems, the Label governs the Field in that respect.
Since mostly the Labels will be in the page header section, the formatting of the Fields should be independent from the Label. Or at least LO creates the false impression, that one can set the "Auto Grow" attribute of the Field, which in fact you can do but after saving and reopening it will reflect the setting of the Label again.
This would indeed be a bug by most user's standards, as the behaviour is unexpected in relation to the choice of field selected to autogrow.
No doubt, as Robert has mentioned, this could be to do with an incompletely implemented part of the code that was introduced when this feature was developed (unless some other change has accidentally broken this functionality since then).
@Ilhan : care to take a look ?