Created attachment 65195 [details] The Base file that experiences this bug behavior. Problem description: Steps to reproduce: 1. Create a tabular report with grouping on one field and ensure creation of report and that Base application has been saved. 2. Edit report 3. Try to resize a column to a size greater than the space available for that column. Current behavior: Alert box pops up informing not enough space available; application subsequently crashes requiring recovery of file AND recreation of report. Expected behavior: Popup alert box, allow "OK", return to editing. Platform (if different from the browser): Browser: Opera/9.80 (X11; Linux i686; U; en) Presto/2.10.289 Version/12.00
No idea how to reproduce the Bug! What the heck is "a column"? @reporter: Thank you for your report – unfortunately important information is missing. May be hints on <http://wiki.documentfoundation.org/BugReport> will help you to find out what information will be useful to reproduce your problem? If you believe that that is really sophisticated please as for Help on a user mailing list Please: - Write a meaningful Summary describing exactly what the problem is - Attach a sample document (not only screenshot) or refer to an existing sample document in an other Bug with a link; to attach a file to this bug report, just click on "Add an attachment" right on this page. - Attach screenshots with comments if you believe that that might explain the problem better than a text comment. Best way is to insert your screenshots into a DRAW document and to add comments that explain what you want to show - Contribute a document related step by step instruction containing every key press and every mouse click how to reproduce your problem (similar to example in Bug 43431) - add information -- concerning your PC (video card, RAM) -- concerning your OS (Version, Distribution, Language) -- concerning your LibO localization (UI language, Locale setting) –- Libo settings that might be related to your problems (video hardware acceleration ...) -- how you launch LibO and how you opened the sample document
Well thank you for taking a look at this report. But I don't know why you wouldn't know what a column is. That is standard database nomenclature. A column is a set of data values of a particular simple type, one for each row of the table. [ref: http://en.wikipedia.org/wiki/Column_(database)] A tabular report has rows and columns. The columns are arranged left to right (in this case) and the rows run from top to bottom just like in any standard SQL database application. Since it is well-known in SQL terminology what a column is, I am at a loss as to how else to explain it.
I could not reproduce it, but I haven't any LO 3.4. In LO 3.3.4 and LO 3.5.x and LO 3.6.0.4 appears a popup "This operation is not allowed. The control overlaps with another one". When I click "OK" the value wasn't changed. No crash here. My system: OpenSuSE 11.4, 32bit rpm-Linux, LO 3.3.4 and LO 3.6.0.4 For other people, who will test the behaviour. 1) Open the report of the attachment for editing. 2) Klick F4 or choose "properties", if not shown. 3) Klick on the datafield "FirstName". 4) When you wanted to change the width of this filed, you could try it with the mouse or in the properties by typing a value greater than 3,35 cm in the properties. 4a) Changing with the mouse: the box looks red, isn't allowed, no popup. 4b) Changing withd by keys: Over 3,35cm a popup appears. 5) Klick "OK" and the value isn't changed. ... and a little hint to "columns". There are fields in the report for data. That would look like columns, when you will position them like columns. When you will have a look at the report: Edit → Column Header/Footer. There are planned another kind of columns in the report-builder, but they dont work at this time. This function is missing columns of the page-setup. The term "column" without declaration is misleading in a report of report-builder.
@Robert, concerning "column" -> what´s your opinion: change/edit the subject of this bugreport? "REPORTBUILDER: Application crashes when over-sizing column in tabular report"
@robert@familiegrosskopf.de, thank you for posting clearer steps to reproduce. I should add that the problem does not occur when trying to resize with the mouse. It occurs when resizing via the Properties dialog. Regarding terminology, I learned along time ago that when talking SQL, we are to talk in terms of rows/columns and not in terms of records/fields (as in BASIC). But I defer to your greater knowledge. Is "datafield", then, the accepted term? I'm all for changing the subject to be more clear. Do I have to do that?
(In reply to comment #5) > I'm all for changing the subject to be more clear. Do I have to do that? Yes.
I did some additional tests with various Versions on WIN, no Crash. My LibO 3.4.3 on Ubuntu 11 (VirtualBox) does not support Database?!?!. I will update and test again later. @T. Lee: Thx for additional info how to reproduce. Is that problem really limited to field width or does it also occur for height? It would be great if you could do a test with 3.5 or 3.6, may be with a parallel installation <https://wiki.documentfoundation.org/Installing_in_parallel>; there will be no more fixes for 3.4. @Jochen: Who was able to reproduce the problem?
(In reply to comment #7) > @Jochen: > Who was able to reproduce the problem? @Rainer: I´m not using Linux. @T. Lee: Please update the description of the error like Steps to reproduce: 1. Create a tabular report with grouping on one field and ensure creation of report and that Base application has been saved. 2. Edit report 3. Try to resize a datafield via the Properties dialog to a size greater than the space available for that column. Current behavior: Alert box pops up informing not enough space available; application subsequently crashes requiring recovery of file AND recreation of report. Expected behavior: Popup alert box, allow "OK", return to editing. Platform (if different from the browser): Browser: Opera/9.80 (X11; Linux i686; U; en) Presto/2.10.289 Version/12.00 The problem does not occur when trying to resize with the mouse.
@Jochen, I don't see how to edit the description. However, per Rainer Bielefeld's request, I tried to reproduce the problem on a different machine with, IIRC, LO v3.5.5.3 with an address book created and edited in the same manner. The problem did not occur. So if there will be no more fixes for v3.4, then this is essentially a dead issue. Correct? If so, then please feel free to close, kill, or whatever you feel is appropriate to do with this bug report. Thank you for all your help.
(In reply to comment #9) > So if there will be no more fixes for v3.4, then this is essentially a dead > issue. Correct? > > If so, then please feel free to close, kill, or whatever you feel is > appropriate to do with this bug report. I set this bug to "Resolved" and "Fixed", because it is a problem of 3.4.6 and nor problem of the actual 3.5,x bzw. 3.6 - version. Ther won't be a fix for LO 3.4.6.
@T. Lee: Thank you for additional research. Please feel free to reopen this bug if you find out that the problem has reappeared with the current stable LibreOffice version (that can happen, please see my comments below!). @Robert: FIXED is reserved for Bugs with known fix due to <https://bugs.freedesktop.org/page.cgi?id=fields.html#status> Please use WORKSFORME if fix is not known (and add target info in brackets for the Version where it has been observed that the bug has vanished). The distinction is important because WFM-"fixes" can not be backported to more early version (because it's not known what has fixed the bug), and the solution is much less reliable than a tested and may be even reviewed Fix with a known commit. Thank you for your assistance!