In a report that contains at least one field with a highly variable amount of data from row to row, it is often desirable for that field to take as many lines as it needs on the printout, but not to reserve several lines on *all* data rows just to accomodate the rows that have more data (thereby wasting space). This is easily achieved after the report is generated by editing the resulting writer document and setting "optimal row height" on the rows that contain the given field (that is all rows in a tabular-style layout). We should have a way to specify this in the report design itself. Add a boolean property "autogrow" (or similar) to every control. In the generated writer document, at the moment the table(s) are created to hold the data, set the "optimal height" for rows that contain at least one control whose autogrow property is set to true. For bonus points, also add a way to fix the height of the whole detail section (all rows in the lowest grouping, if any). This is useful in layouts where things have to be at a fixed position on the page.
Thanks for new idea Please, attach small Database document that demonstrates this problem
Created attachment 58813 [details] example database One table (Assets), two rows. One has short text in "comments", the other has long text in comments. With the current system, one can only get two different kinds of "wrong" results: - "wrong result 1" (report in this database document): the short text takes too much space - "wrong result 2" (attached odt file and Assets report in this database document): the long text is cut to fit within one line, as indicated by a red triangle. The result I would like is in attachment "right result". Obtained by editing "wrong result 2", selecting the two data row and selecting optimal row height for those.
Created attachment 58814 [details] wrong result 2
Created attachment 58816 [details] right result
Thanks for attachments To produce last attachment (3-th) we do: 1. Select table 2. Right click table, select Row->Hight 3. Check box "Fit to size" And now I have another question: what wrong if we do this behaviour as default. I see one advantage: user will not have problems with data that accidentally becomes hidden outside of cell. This may produce data loss when document will printed. This may increase productivity, because users will have no need to check this option each time. But may be exist disadvantages for make this as default?
(In reply to comment #5) > And now I have another question: what wrong if we do this behaviour as default. Well, a row (cell) could take far too much space and fuckup the layout (depending on how the layout is done). Whether the "fit to size" thing is desirable depends on the data being shown... FWIW, in MS Access, one can choose this kind of thing per-control (AutoGrow and AutoShrink). This allows to do e.g.: Name Number Data Eleonor 1 short data Lionel M 2 short data Ted when the name of number one is really "Eleonora Battista Almeire", number 2 "Lionel Mamane" > I see one advantage: user will not have problems with data that accidentally > becomes hidden outside of cell. This may produce data loss when document will > printed. This may increase productivity, because users will have no need to > check this option each time. > > But may be exist disadvantages for make this as default?
(In reply to comment #5) > And now I have another question: what wrong if we do this behaviour as default. Well, a row (cell) could take far too much space and fuckup the layout (depending on how the layout is done). Whether the "fit to size" thing is desirable depends on the data being shown... FWIW, in MS Access, one can choose this kind of thing per-control (AutoGrow and AutoShrink). This allows to do e.g.: Name Number Data Eleonor 1 short data Lionel M 2 short data Ted 3 long data, blah, blah word wrap, lorem ispsum doloret ma Pete non dolet. Bruce 4 long data, blah, blah word Willis wrap, lorem ispsum doloret ma Pete non dolet. when the name of number one is really "Eleonora Battista Almeire", number 2 "Lionel Mamane" and number 3 just "Ted". As a short prefix of the name is all that one needs to disambiguate between rows, one does not want to waste space (neither horizontal, nor vertical) to show full name, so that the rows take as many lines as the data needs. Short data -> one line even if name is long, and long data -> many rows even if name is short. If many rows anyway, *do* use the extra space for word-wrapping the name. I don't quite see a way to achieve that with LibO, but at least we can put a per-row (instead of per-control) choice, which is already better than the current. So, really, it should be an option. The *default* state of that option could be "enabled", that's up for discussion.
Thanks for additional explanations and examples > FWIW, in MS Access, one can choose this kind of thing per-control (AutoGrow and > AutoShrink). This allows to do e.g. It makes sense to reuse user's knowledge. If user learned something useful in one program, IMHO it is useful to allow to him/her use it in another program. Now we have enough knowledge about how this should be. Let we see how it will be implemented. Thanks for idea. And thanks in future for implementing.
*** Bug 40229 has been marked as a duplicate of this bug. ***
As a temporary work-around, one can use the following macro to open a report and put every row to autoheight: Dim rpt as Object rpt = ThisDatabaseDocument.ReportDocuments.getByName(rptName).open Dim tbls as Object, tbl as Object tbls = rpt.getTextTables() dim j as Integer for j = 0 to tbls.count() - 1 tbl = tbls.getByIndex(j) if Left$(tbl.name, 6) = "Detail" then Dim rows as Object, col as long rows = tbl.Rows dim i as integer For i = 0 to rows.count - 1 dim row as Object row = rows.getByIndex(i) row.IsAutoHeight = True Next i endif next j
It would really be nice if this "bug" could be fixed in the report builder! For me, it would convert Report Builder into something usable! Please push this to the top of the list of things that need to be fixed.
*** Bug 50105 has been marked as a duplicate of this bug. ***
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Hello, I am starting work on this bug.
(In reply to comment #14) > I am starting work on this bug. Hi. How is the work going? Do you have any draft? Do you need any help / review / pointer?
Hello, I have some questions about this bug. I will try describe them here or on IRC tomorrow. Sorry for the delay Michal Strnad On 3.4.2014 16:05, bugzilla-daemon@freedesktop.org wrote: > > *Comment # 15 <https://bugs.freedesktop.org/show_bug.cgi?id=45789#c15> > on bug 45789 <https://bugs.freedesktop.org/show_bug.cgi?id=45789> from > Lionel Elie Mamane <mailto:lionel@mamane.lu> * > (In reply tocomment #14) > > I am starting work on this bug. > > Hi. How is the work going? Do you have any draft? Do you need any help / review > / pointer? > ------------------------------------------------------------------------ > You are receiving this mail because: > > * You are the assignee for the bug. >
(In reply to comment #16) > I have some questions about this bug. I will try describe them here or > on IRC tomorrow. I won't be on IRC (travelling for vacation), but if you have general questions, you may find good help there. For Base-specific or this-bug-specific questions, please post them as comments to this bug, I'll try to check this bug from time to time.
Michal? Any news on your work on this bug? Any question? Do you still intend to work on it?
Is this still being worked on? I'm honestly really surprised it's not a feature, it would make the reporting engine so much more useful.
No answer from assignee -> marking as available again
Hi, I am trying to work on this Bug but I don't know where to start. Maybe you can help me and tell me in which file I have to look for.
To add the property "AutoGrow" to controls, you need to add it: 1) To the file format in reportdesign/source/filter/xml/ (probably xmlReportElementBase.* or xmlReportElement.*) 2) To the actual in-memory "model" (implementation) of controls: I suggest you start with Formatted field: reportdesign/source/core/api/FormattedField.cxx reportdesign/source/core/inc/FormattedField.hxx 3) Have the actual treatment (generation) of the report take these into account. The treatment happens in reportbuilder/java/org/libreoffice/report/
For an example of a commit that added a new property (albeit not to controls, the the report as a whole), see http://cgit.freedesktop.org/libreoffice/core/commit/?id=4178806bb010129f3b13b62825476666fe48ddcd It shows e.g. how to add a new token to the XML format.
The reportbuilder creates an odt file (OpenDocument text), but not through Writer. It creates the XML directly and *then* starts writer on it for display / print / etc. When working on it, I've found the ODF reference a good help to understand what is being generated and what needs to be generated. https://lists.oasis-open.org/archives/tc-announce/201201/msg00001.html Here, in particular, we are generating tables http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415580_253892949 Need to find how in the XML a table row with automatic height is coded. To find out that kind of things, create an odt document with writer, with a table. Save it. Then make *one* change, namely changing *one* row to "automatic height". Save it under a different name. Compare the two documents (that is, the XML that is within the ZIP structure). xmlindent is your friend. Most probably one attribute is added/changed in the <table:table-row> element. That's the result you need to produce in ReportBuilder when the "AutoGrow" feature is on.
The code that creates a new row seems to be private void startRow(final AttributeMap attrs) in reportbuilder/java/org/libreoffice/report/pentaho/output/text/TextRawReportTarget look where/how this is called. The decision to apply "automatic height" or not will most probably be in the/a caller of this startRow (or their caller). Thread.dumpStack() is your friend :)
Finally, the *UI* for handling properties of controls is apparently in reportdesign/source/ui/ You can look at how the other properties are handled there.
These pointers should hopefully get you started. Let me know if you run into difficulties or have other questions. Because of the LibreOffice conference, I might be less avaible from 2 to 7 September.
Thank you for the information! I'll try it on monday
I think this bug is too difficult for me yet, so I'll take an easier bug first to learn more about libreoffice. :)
Don't worry guys. I got this
(In reply to Omar Syed from comment #30) > Don't worry guys. I got this I look forward to reviewing your patch ! Let me knwo when it, or a draft of it, is ready.
Adding self to CC if not already on
I was not able to reproduce this bug with the example database and the source code at commit 5d388443b9809e73202ce551bcffa10d442094ca from 12 Feb 2015. Is it still up-to-date or it was fixed?
(In reply to Zlatko Kostadinow from comment #33) > I was not able to reproduce this bug with the example database and the > source code at commit 5d388443b9809e73202ce551bcffa10d442094ca from 12 Feb > 2015. Is it still up-to-date or it was fixed? This enhancement request is still pending.
Hello, I want to work at this bug, but I fear I need help :) Please sorry my bad english.
(In reply to lukas.mentel from comment #35) > Hello, > I want to work at this bug, but I fear I need help :) > Please sorry my bad english. Please read particularly comments 22 to 26. Then come back to me with any question or difficulty you have.
How can I execute logerrit? If I try the command ./logerrit setup, the computer asks for an app to open (Windows 8.1).
(In reply to lukas.mentel from comment #37) > How can I execute logerrit? If I try the command ./logerrit setup, the > computer asks for an app to open (Windows 8.1). Hmm... I'm not using Microsoft Windows, so I suggest you ask on the mailing list or on IRC.
Is this still an issue? Thanks.
(In reply to derrick rocha from comment #39) > Is this still an issue? Thanks. yes
Hello, I am starting work on this bug. I want ask questions to you. Please can you help me? First of all, I don't know where the start. Also will i work any code files? Thank you for your suggestion.
(In reply to kerem from comment #41) > Hello, > > I am starting work on this bug. I want ask questions to you. Please can you > help me? > > First of all, I don't know where the start. Also will i work any code files? > > Thank you for your suggestion. Please read particularly comments 22 to 26. Then come back to me with any question or difficulty you have.
(In reply to Lionel Elie Mamane from comment #42) > (In reply to kerem from comment #41) > > Hello, > > > > I am starting work on this bug. I want ask questions to you. Please can you > > help me? > > > > First of all, I don't know where the start. Also will i work any code files? > > > > Thank you for your suggestion. > > Please read particularly comments 22 to 26. Then come back to me with any > question or difficulty you have. In comment 24, reportbuilder creates an odt file, not through Writer. I can't this. How to create odt file?
(In reply to kerem from comment #43) > In comment 24, reportbuilder creates an odt file, not through Writer. I > can't this. How to create odt file? An ODT file is basically a ZIP structure with XML in it. In reportbuilder, the Java top-level class that does the process seems to be in file reportbuilder/java/org/libreoffice/report/pentaho/output/text/TextRawReportTarget.java (in combination with the external jfreereport), but that is not where you will need to intervene, but in the code that creates a table row. The code responsible for a cell is basically reportbuilder/java/org/libreoffice/report/pentaho/layoutprocessor/TableCellLayoutController.java My original idea was to find the code responsible for a row and inject the attribute for "fit to size" row height there. However, now that I take a fresh look at it, I realise that the <table:table-row> tags are probably copied unchanged from the report definition. So it might be easier to change the way the report definition is saved rather than the way it is processed. The saving of the report definition happens in C++, in reportdesign/source/filter/xml/ I think it is particularly in reportdesign/source/filter/xml/xmlExport.cxx function void ORptExport::exportContainer(const Reference< XSection>& _xSection) looks relevant; need to set the right attribute or style for "automatic height" there.
(In reply to Lionel Elie Mamane from comment #44) > (In reply to kerem from comment #43) > > In comment 24, reportbuilder creates an odt file, not through Writer. I > > can't this. How to create odt file? > > An ODT file is basically a ZIP structure with XML in it. > > In reportbuilder, the Java top-level class that does the process seems to be > in file > reportbuilder/java/org/libreoffice/report/pentaho/output/text/ > TextRawReportTarget.java > (in combination with the external jfreereport), but that is not where you > will need to intervene, but in the code that creates a table row. > > The code responsible for a cell is basically > reportbuilder/java/org/libreoffice/report/pentaho/layoutprocessor/ > TableCellLayoutController.java > > My original idea was to find the code responsible for a row and inject the > attribute for "fit to size" row height there. However, now that I take a > fresh look at it, I realise that the <table:table-row> tags are probably > copied unchanged from the report definition. So it might be easier to change > the way the report definition is saved rather than the way it is processed. > > The saving of the report definition happens in C++, in > reportdesign/source/filter/xml/ > I think it is particularly in reportdesign/source/filter/xml/xmlExport.cxx > function void ORptExport::exportContainer(const Reference< XSection>& > _xSection) > looks relevant; need to set the right attribute or style for "automatic > height" there. Okey I understand. So I change something in function void ORptExport::exportContainer(const Reference< XSection>&_xSection). I change that about the "automatic height", is true? In addition to, are there any your suggestions? Thank you.
Migrating Whiteboard tags to Keywords: (easyHack, difficultyInteresting, skillCpp, skillJava, topicUI) [NinjaEdit]
I sent following patch for this bug; https://gerrit.libreoffice.org/#/c/20751/
I sent following new patch for this bug; https://gerrit.libreoffice.org/#/c/21761/1
(In reply to kerem from comment #45) > (In reply to Lionel Elie Mamane from comment #44) >> The saving of the report definition happens in C++, in >> reportdesign/source/filter/xml/ >> I think it is particularly in reportdesign/source/filter/xml/xmlExport.cxx >> function void ORptExport::exportContainer(const Reference< XSection>& >> _xSection) >> looks relevant; need to set the right attribute or style for "automatic >> height" there. > Okey I understand. So I change something in function void > ORptExport::exportContainer(const Reference< XSection>&_xSection). I change > that about the "automatic height", is true? In addition to, are there any > your suggestions? Sorry it took me so long to answer. Basically, yes, that is my guess, but that is about step 3 from comment 22. We also (first?) need to do steps 1 and 2 from comment 22. See also comment 24 and comment 26. To summarise: the work is to add a property "AutoGrow" to every control. It needs to be added to the control models and to the UI that allows to user to set that property. Then, in RptExport::exportContainer, if any of the controls of this row has "AutoGrow" set to true, then set the "automatic row height" attribute" on the whole row. Code pointers are in comment 22, except that in step 3, the code pointer is probably wrong and should be replaced by what I say in comment 44. Steps 1 and 2 are still valid. Sorry for the mixup.
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
*** Bug 114387 has been marked as a duplicate of this bug. ***
Thank you Alex for spotting and e-mailing me that my enhancement Bug 114387 has already been submitted as 45789. I apologize for any inconvenience caused.
*** Bug 116210 has been marked as a duplicate of this bug. ***
Created attachment 140395 [details] another, larger database to demo this bug 6 years, 16 volunteers, 4 duplicates, tough bug! (-: My attachment here today is a more comprehensive Base report to further demo this issue. :-) 1) I think we might be starting with the wrong bug. No really, the more important bug I think, is that the LO source code is mostly too hard to work on. I have myself begun to study the source base, but in most places it lacks the most basic comments to help the unfamiliar figure out how it works, to be able to read the code to even work on bugs like this. (A few years go by and I can't even read my own code without a few comments to refresh my memory. And as we all get older, this issue gets worse.) So what I think is needed _first_, is to work together (or alone) to start to add sufficient comments to the code base to help new coders find their way around. One needs to be able to read the code without going to an extreme amount of work. I am willing to help with such an effort, as I begin to try and read the code myself. (Please see more specific question about this below.) 2) As for THIS bug, and having used database report writers (plural) with CanGrow and CanShrink type features, I am definitely of the opinion that BOTH of these properties are required, not just AutoGrow, and need to be added to all controls. The reason for CanShrink is that if no data is in group, it is often desirable to fully collapse the group, so as to save paper space where it's not needed. But this can only reasonably work if CanShrink is also available. In this case you would set the can-shrink on all fields in the group, and also on the group itself. Furthermore, I think it would make no sense to fix only half of this problem, and to miss the other half, especially when it is so hard to do, and these are so closely related. 3) Finally, and sadly, the Base report writer, as it is, is extremely slow. Just try to produce a report with 100 pages sometime. It takes forever. So I think any work done on #1 or #2 above should keep a watchful eye on someday re-writing the slower parts, (or the whole thing) to be faster. For one, I can see from the above comments that Java is involved. At a minimum I think that it someday needs to get rewritten in some flavor of C, as I have found java to sometimes be slow. SUMMARY: So my point #1 above (call for code comments), becomes even more important in the long haul: It will help fix things now, and make things faster in the future. MY QUESTION: Are code comment-only commits (i.e. comments w/o any code changes) welcome to the powers that be here? I realize that the people who wrote this are probably long gone, so any comments will only try to recapture some of what was in their heads, and comments will definitely be a work in progress, so some tolerance for not getting them right the first time would be appreciated. Also my call for comments is not just about this bug. It appears to me that there are a whole backlog of Base bugs that are in the category of: Given the volunteer time we have available, 'too hard' to fix right now. Can I get a green light to start to add comments to the code to make it more readable, AND if yes, is there some community tolerance for how this is to be done, as any comments might be better than none? I have some particular commenting styles I've developed over the years, but even I don't always stick to my commenting styles. :-) For one I never like processing comments into documentation, so I don't do that. Comments I think are to help engineers read the code, period. Thanks. ____________ I'm so independent that I often won't do what I put on my own to-do list. :-~
(In reply to Howard Johnson from comment #54) > MY QUESTION: Are code comment-only commits (i.e. comments w/o any code > changes) welcome to the powers that be here? > > I realize that the people who wrote this are probably long gone, so any > comments will only try to recapture some of what was in their heads, and > comments will definitely be a work in progress, so some tolerance for not > getting them right the first time would be appreciated. > > Also my call for comments is not just about this bug. It appears to me that > there are a whole backlog of Base bugs that are in the category of: Given > the volunteer time we have available, 'too hard' to fix right now. > > > Can I get a green light to start to add comments to the code to make it more > readable, AND if yes, is there some community tolerance for how this is to > be done, as any comments might be better than none? > > I have some particular commenting styles I've developed over the years, but > even I don't always stick to my commenting styles. :-) For one I never > like processing comments into documentation, so I don't do that. Comments I > think are to help engineers read the code, period. Hi Howard, I appreciate your offer. I'm not one of the deciders here, I just like to comment, that it might be better to open a new bug fot this. You might have more readers then.
(In reply to Howard Johnson from comment #54) > No really, the more important bug I think, is that the LO source code is > mostly too hard to work on. > MY QUESTION: Are code comment-only commits (i.e. comments w/o any code > changes) welcome to the powers that be here? I expect so. I expect the right place to discuss that is the development mailing list at https://lists.freedesktop.org/mailman/listinfo/libreoffice > 2) As for THIS bug, and having used database report writers (plural) > with CanGrow and CanShrink type features, I am definitely of the opinion > that BOTH of these properties are required, not just AutoGrow, and need > to be added to all controls. Yes, the way I was suggesting this to be implemented is actually equivalent to setting both "CanShrink" and "CanGrow". Setting it per-row can be done relatively easily with the current infrastructure. Setting it per-control requires a deeper redesign of report builder, or a new feature in ODT/Writer. Report builder now "just" creates an ODT document, and Writer does all the actual layouting. So per-control would require that *Writer* support the feature of "autogrow" (which it calls "optimal row height") per cell, and not only per row.
(In reply to Lionel Elie Mamane from comment #56) > ..the right place to discuss that is the development > mailing list at https://lists.freedesktop.org/mailman/listinfo/libreoffice Thanks. I said >>...report writer, .. extremely slow To briefly follow up on this, after days of looking, I just discovered why one of my base reports was so extremely slow saving and reporting, and how to easily fix it. I'll submit in another bug report.
No need for input from UX I guess. Removing the ML from CC.
Hello, I want to work on this bug, it looks interesting and will be my second contribution to libreoffice.
Current status: After examination of the code, I added some ids and properties for the new property Autogrow. Now the new property is displayed if a report is in edition and a control is selected. Next step would be, that I store this property into the file, but I have a question here. This is how the property of a row is currently generated: <style:style style:name="Detail.1" style:family="table-row"> <style:table-row-properties style:row-height="0.499cm"/> </style:style> If I later manually open the generated odt file and set the row to optimal height, then it is saved without "style:row-height" in this way: <style:style style:name="Detail.1" style:family="table-row"/> So how do I save this new property? My suggestions are: 1. Just don't save style:row-height? 2. Add new style property style:autogrow: <style:table-row-properties style:row-height="0.499cm" style:autogrow="true" /> 3. Replace style:row-height with new property: <style:table-row-properties style:autogrow="true" /> 4. Write "autogrow" into style:row-height <style:table-row-properties style:row-height="autogrow"/> 5...? I would also like to know, if there are naming conventions to concern if autogrow is introduced here in this xml formatted file?
(In reply to Ilhan Yesil from comment #60) > Current status: After examination of the code, I added some ids and > properties for the new property Autogrow. Now the new property is displayed > if a report is in edition and a control is selected. Great progress! > Next step would be, that I store this property into the file, (...) > So how do I save this new property? style:use-optimal-row-height="true" See http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1420232_253892949
style:use-optimal-row-height is saved now. -<style:style style:name="ro4" style:family="table-row"> <style:table-row-properties style:use-optimal-row-height="true" style:row-height="0.499cm"/> </style:style> But if i reopen the report for edit, the property is false. Is the property saved somewhere else then in content.xml? I debugged the code while it is importing content.xml and other sections of the code. The property "use-optimal-row-height" is parsed correctly, but how this information is to deliver to the control? I need an advice please.
(In reply to Ilhan Yesil from comment #62) > style:use-optimal-row-height is saved now. Great. > But if I reopen the report for edit, the property is false. > > The property "use-optimal-row-height" is parsed correctly, but how this > information is to deliver to the control? Change the parser to apply the autogrow property you created to each affected control, that is each control of this row. Would it be possible to see your "in progress" code? Maybe I could be more specific upon seeing it.
I've submitted my current incomplete status for a review. https://gerrit.libreoffice.org/#/c/53977/
I solved it, the flag "AutoGrow" is now read. I uploaded a new patch set. My next step would be to work on the JAVA code. I've here a problem. When I open the report, the fields are filled like this: <text:p text:style-name="P1">Any[Type[com.sun.star.sdbc.XClob], com.sun.star.bridges.jni_uno.JNI_proxy@1f543bd9 [oid=1e56ce2f880;mscx[0];e442f7c441644aebaca2a57af370d4f1, type=com.sun.star.sdbc.XClob]]</text:p> I think it has to do with the firebird driver, but I've not found what to do. With the installed version 6.0.3.2 there is no problem. I'm working on a Windows 10 machine.
(In reply to Ilhan Yesil from comment #65) > > I think it has to do with the firebird driver, but I've not found what to > do. With the installed version 6.0.3.2 there is no problem. I'm working on a > Windows 10 machine. Don't try to solve Firebird-bugs with workarounds here. If you could solve the problem for the internal HSQLDB we must have a look what's going wrong with Firebird an reports. Great there is somebody who tries to solve this problem of automatic row-height.
(In reply to Ilhan Yesil from comment #65) > I solved it, the flag "AutoGrow" is now read. I uploaded a new patch set. > > My next step would be to work on the JAVA code. I've here a problem. When I > open the report, the fields are filled like this: > > <text:p text:style-name="P1">Any[Type[com.sun.star.sdbc.XClob], > com.sun.star.bridges.jni_uno.JNI_proxy@1f543bd9 > [oid=1e56ce2f880;mscx[0];e442f7c441644aebaca2a57af370d4f1, > type=com.sun.star.sdbc.XClob]]</text:p> > > I think it has to do with the firebird driver, but I've not found what to > do. With the installed version 6.0.3.2 there is no problem. I'm working on a > Windows 10 machine. Is this a problem that is introduced with your patch, or does it also happen without your patch? If it exists without your patch, that's a separate problem/bug, I would recommend the same as Robert: My guess is that this is because a column of the database you try has a "Memo" (very large text / Character large object) type. Do your tests with plain integer / varchar / char columns and you should not see this problem, which will allow you to concentrate on this enhancement here. (If afterwards, you want to solve the CLOB bug as a separate work, that's not refused) :)
(In reply to Lionel Elie Mamane from comment #67) Windows 10 machine. > > Is this a problem that is introduced with your patch, or does it also happen > without your patch? If it exists without your patch, that's a separate > problem/bug, I would recommend the same as Robert: No, it's not introduced with my patch, I saw this also before coding. I used your sample database for the test.
My code compiles on Windows 10 (MSVC 2015, cygwin), but after each commit I get this: CommandLine Error: Option 'disable-symbolication' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options Seems it has to do with clang-format. Because of this, I've no last code check before I submit to loggerrit. On jenkins I had some build errors, I assume it has to do with this missing code check. Can someone give me hints?
Sorry, i agree it was not suitable to put my last question here. I think it works now as required.
With the last patch submitted it works now. It was not necessary to touch Java code. https://gerrit.libreoffice.org/#/c/53977/
A polite ping, still working on this bug?
Dear Ilhan Yesil, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
(In reply to Ilhan Yesil from comment #71) > With the last patch submitted it works now. It was not necessary to touch > Java code. > > https://gerrit.libreoffice.org/#/c/53977/ Hi! When will this Patch arrive? I still have the problem ...
Ilhan Yesil committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/260caebf8a2382bcde1fb9ff74ceb1b940654e6f%5E%21 tdf#45789 [API CHANGE] Automatic row height in reports It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.