Previously I could set max size to -1 on multiline input text boxes and the box would still be usable and editable, up to an arbitrary length (I know it worked well to at least about 57k chars before, because I used it to input and edit that much text without issues in previous versions, at least up to around 4.0 or 4.3 or so). Now, I can do that but the box is readable but not editable with a -1 maximum length, unless it has a nonzero maximum size. It's pretty easy to reproduce, any multi line input text box with max length of -1 is uneditable as far as I can tell, even a text box that's part of a table control. The issue only affects multi line input text boxes, and not single line input text boxes. Single line text boxes still work great with a max length of -1. The maximum maximum size is 32767, which is way too small. (This may or may not be different than before, I always used -1 before). Anything higher is not allowed when I go to the form control properties field and try to set the maximum size higher. I don't think it matters, but I'm using a MariaDB backend, using the MySQL connector. (It works single line input, but not multiline input, even on the same field in the same form at the same time, so it's hard to imagine that the connector could be the problem, otherwise it would probably fail single line input too). I'm using the version of libreoffice in debian jessie backports, 1:5.1.1-1~bpo8+1. 1) Please fix the regression, and make -1 max length multiline input text boxes editable at arbitrary length again like it was before. I think this is by far the best solution. Any other solution would break a lot of people's forms, including mine. 2) (Should also be done in addition to (1)) You should also probably nake the maximum maximum length (not a typo) a lot longer, say the length of a MEDIUMTEXT, or at least as long as your current textbox class can take which is clearly much more than 32k based on past experience. I know the text box can handle more, because it did previously, so even if the length of a mediumtext is too high, 32767 isn't nearly enough. Thanks for your hard work, I love base!
This seems to have begun at the below commit. Adding Cc: to Matteo Casalin; Could you possibly take a look at this one? Thanks 5bd4464fb6178053009ae5feab788929014c147c is the first bad commit commit 5bd4464fb6178053009ae5feab788929014c147c Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sun Aug 16 05:32:04 2015 -0700 source 98244c3cb47824babc746ebc14a199977e9768d1 source 98244c3cb47824babc746ebc14a199977e9768d1 author Matteo Casalin <matteo.casalin@yahoo.com> 2015-08-15 17:35:32 (GMT) committer Matteo Casalin <matteo.casalin@yahoo.com> 2015-08-16 07:10:21 (GMT) commit 98244c3cb47824babc746ebc14a199977e9768d1 (patch) tree 0077631b678997f61a1fae245e32467bd7afbe00 parent caa828da96b120f5a3c979237081c29f8c2f3848 (diff) sal_uLong to sal_Int32/long
I just tried 5.1.2.-3~bpo8+1 from Debian jessie-backports, and the bug is still there. I did notice another wrinkle. While you can't input anything in a field with a maxlength of -1, if you paste something in it (of any length, short or long) it pops up a box that says "The inserted text exceeded the maximum length of this text field. The text was truncated." and it then replaces the pasted text with "!!br0ken!!" in the input field which can then be saved and loaded but not edited.
I'll have a look at this as soon as I can, this is almost certainly due to changing from unsigned to signed integer types.
I just submitted a possible patch to gerrit. Is there any way to test it? From comment 1 it seems controlled by some script, could it be uploaded with related instructions?
(In reply to Matteo Casalin from comment #4) > I just submitted a possible patch to gerrit. > Is there any way to test it? From comment 1 it seems controlled by some > script, could it be uploaded with related instructions? Hello Matteo, comment 1 is result from bibisecting. For test just try to set multiline text box. @Ray, please could you post some printscreens for Matteo? Thank you
@raal: I meant the bug description, sorry for the confusion. @Ray: I know nothing about Base, so I need a detailed procedure in order to reproduce the bug and verify the fix.
Thanks for fixing the bug, or at least trying to! I really appreciate your time and effort. If there's anything else I can do just ask. I provided some instructions below. DETAILED INSTRUCTIONS TO SEE REGRESSION: Create a new base document. Then click finish right away (don't bother trying to set up a database, we aren't going to try to store anything). Then click forms on the left side, it's between queries and reports. Then click create form in design view (kind of the top middle of the screen). Then click the text box icon and draw a big square text box that is big enough for many lines. Right click the text box, hit "Control..." Then set "Max. text length" to -1, the default "Text type" is multi-line, but if it isn't already multi-line, set it to multi-line. Close the properties window with the x on the top right. Hit the save icon, use the default name which will be Form1 Then hit the x at the top right of the form editor to close the window. Then double click on Form1, which should be about halfway down the left side of the screen toward the middle. Click in the box and try to type. Nothing will happen (This is a bug, it used to take any amount of text, at least up to about 90,000 characters, and probably well beyond that, but I never went further). If the regression is really completely fixed, you should be able to not only edit it, you should be able to paste at least 90k characters worth of text without it truncating anything. If it is accepting input, try pasting in a whole lot of text to make sure that it doesn't truncate at 32767, because it didn't truncate there before in 4.x. For comparison, you can edit form 1 (right click on "Form1" from the main Base screen, it's the same thing you left clicked to open the form) and then set the "Max text length" property to something positive (edit it the same way you did last time), and then save. Then open Form1 again and it will again be editable. This is not part of the bug, it is just a way to compare behavior with different values of Max text length so that you can see what it is supposed to do. Thanks!
Thanks Ray, I should be able to perform some debug during the upcoming weekend.
Just an update: I tested the patch I wrote and it seems OK to me. I'm waiting for an additional review (just asked the list) and instructions on how to proceed for it to be backported to the 5.1 branch. About your second request, after setting the maximum text length to -1 I was able to paste a 570kB text in the form. Is this what you asked for or was it related to the maximum value that can be used in the control options?
Thank you! I reported a regression between 4.x and 5.x. And yes, it sounds like you fixed exactly what I asked for, so that it works as well as 4.x did. I always use a maximum text length of -1 for long fields, so I don't set the max explicitly for anything that is very large. That was a quick turnaround time too. I really appreciate it. That being said, even though it isn't a regression (I just checked, it was broken in 4.x too, and maybe earlier but I didn't check that far back), and I don't need it fixed, and I wasn't complaining about it originally, there is bug with the maximum text length field that has been there for a very long time. If the actual upper limit of maximum text length is > 500k characters, it seems that the maximum text length field ought to be able to go higher than 32767 unless there is some underlying software engineering reason it shouldn't (i.e. maybe the underlying design of the box can't enforce a max text length of > 32767 without major slowdowns, so the user should be forced to just use -1 for those). If there is an engineering reason it can't be higher than 32767 it should automatically snap back to -1 rather than its last value if someone puts in a higher number. Right now it snaps back to whatever it was before, which is what it did in 4.x. If I can give you any more information about this, or anything else, ask. Whether or not you end up fixing the other longstanding max text length box bug, you fixed the regression, and that makes the software usable for me again. I really appreciate your efforts, both on my particular bug and in general. Thanks!
From my debugging session I verified that the text form maximum length is set by a function that takes a signed 16-bits integer, whose maximum value is indeed 32767. I honestly can't say if that value can be changed, since it could belong to a stable interface. I'll ask the list, though. What I noticed for sure is that the Maximum Length control may take values above that 32767, and this is something that might be addressed after verifying the upper limit that could be used.
Matteo Casalin committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=eca3455190ed9a2c4796e7954f2533dc71cd1ab6 Resolves: tdf#98940 (-1 not mapping to maximum string length anymore) It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Matteo Casalin committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c927b6692257e427d622add6324fc1c55fce9aa3&h=libreoffice-5-1 Resolves: tdf#98940 (-1 not mapping to maximum string length anymore) It will be available in 5.1.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.