Created attachment 176641 [details] LibreOffice Base subform text field blank when focus This bug was filed with the intention to help possible LibreOffice users who may encounter this issue. Some extended searches of the web as well as LibreOffice Bugzilla did not provide a cause or solution. Problem description: In a Base form that was created with an unknown earlier version of LibreOffice/OpenOffice, when editing an existing Text Box (column) in a Table Control subform, the field goes blank on focus by tab or mouseclick. This makes it impossible to edit or copy existing field values. See attachment for an illustration of the issue. Background information: Observed in LibreOffice 7.2.0.4, Windows 10-64. The issue was also observed in earlier LibreOffice 7 versions and possibly in LibreOffice 6 versions. The Table Control form is linked to mysql database. The text field (Text Box) in the subform is linked to a type 'Memo' database field. Workaround: The issue can be resolved by editing the Table Control subform, Text Box properties, General, and changing the property 'Max text length' from "-1" to a positive value. It should be noted that the -1 'Max text length' was not introduced by the user, but apparently as a default by the earlier version of LibreOffice/OpenOffice.
Created attachment 176642 [details] Same field without focus (value shown)
At a guess, I would say that this is linked in some way to the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=eca3455190ed9a2c4796e7954f2533dc71cd1ab6 @Caolan : any ideas ?
(In reply to libreoffice from comment #0) > > Workaround: > The issue can be resolved by editing the Table Control subform, Text Box > properties, General, and changing the property 'Max text length' from "-1" > to a positive value. It should be noted that the -1 'Max text length' was > not introduced by the user, but apparently as a default by the earlier > version of LibreOffice/OpenOffice. This isn't the default in any version I have installed here. Default is '0' ind LO 7.2.4.1, also LO 6.4.7.2 on OpenSUSE 15.2 64bit rpm Linux with internal HSQLDB. It is the same behavior when creating a Memo-field in MariaDB/MySQL and creating a form to connect to this field. Might be this is a special Windows-bug.
@alex: I'd need exact steps to reproduce to be able to help. It could be something similar to that. Also good to give the exact "Version Information" from help, about (click on the copy details icon) to confirm if its a (x64) build or a (x86) build to rule out a possibility where we are narrowing something through a type that's the wrong size on 32 bit windows.
Created attachment 176858 [details] case reproduction and steps to reproduce Steps to reproduce: 1) Open LibreOffice 2) Create a new database using the Database Wizard 3) Accept the defaults and follow the default sequence until Finish and Save 4) In the main program screen, create a new table Table1 in Design view 5) Create a single field of type text(Varchar) and save. Accept the suggestion to create a primary key. 6) Open the table and add a record with some text 7) Create a new form in Design view 8) In the form, create a new Table Control (menu Form) 9) In the Table Element wizard, select the fields of Table1, Add, and Finish 10) In the Table Control, right-click the column header for your 'Text' field 11) Select 'Column...', and enter '-1' in field 'Max text length' 12) Save the form as 'Form1' 13) Open the form, and try to edit or copy your text An example database, created using the steps above, has been attached. Notes: - I assume - but cannot verify - that the -1 max length of the form fields was set by an early OpenOffice version. The issue was found in a database that was created by me between 2000 and 2005 and has been used with various releases of OpenOffice and LibreOffice, as may be the case IRL. In any case, the observed behaviour only occurred in a recent version of LibreOffice (within the last 2-3 years) - This bug has been filed primarily to help possible other users who may be affected (if any). Just trying to contribute to the community. I don't even know if this issue should be considered a feature or a bug, but for sure I was bugged by it. - Program information: Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: en-US (en_NL); UI: en-US Calc: threaded Ruuning on Windows 10 64bit.
(In reply to libreoffice from comment #5) > 11) Select 'Column...', and enter '-1' in field 'Max text length' There is no reason to do this. It isn't the default. You could say it should be impossible to choose '-1' and start an enhancement request. '0' is the default, which doesn't limit the text length. And with this it will work.
(In reply to Robert Großkopf from comment #6) > (In reply to libreoffice from comment #5) > > > 11) Select 'Column...', and enter '-1' in field 'Max text length' > > There is no reason to do this. It isn't the default. You could say it should > be impossible to choose '-1' and start an enhancement request. > Robert, it isn't the default today, but it appears that it was the default back in 5.x when the commit I suggested was made. I'm not entirely certain that this is our bug though. It seems to me that switching and working between AOO and LO might be one of the reasons for the issue reoccurring, as I doubt that the AOO code has reintegrated the commit in question (if indeed, it is that commit at the heart of the issue). The question then would be one of cohesion between AOO generated files and LO-generated ODB files, where the former project is still limping along and being used, while the latter keeps moving ahead.
(In reply to Robert Großkopf from comment #6) > (In reply to libreoffice from comment #5) > > > 11) Select 'Column...', and enter '-1' in field 'Max text length' > > There is no reason to do this. It isn't the default. You could say it should > be impossible to choose '-1' and start an enhancement request. > > '0' is the default, which doesn't limit the text length. And with this it > will work. I agree with you Robert on this, why would anyone now set '-1' as the maxfield length parameter ? To me, the question seems to be what to do about the possible inconsistency it might generate between AOO and LO.
My suggested test scenario Create an ODB file with a form having the required field with AOO using a version from before the LO5.x timeline, as the '-1' would still have been the default (for all I know, it still is, I don't have a functioning version of AOO on Apple M1 silicon with which to test). Then try opening the ODB file in a current version of LO, making some changes to the form, resaving the file, and then re-opening for editing in AOO. Make some changes here again, then resave, and reopen in LO to check. My understanding is that the form definition gets written to the XML of the ODB file, so if there are changes being made surreptitiously on saving to that XML, we should be able to see them with a diff ?
Loading the document conveniently asserts in a debugging version in the problem area. Looking at the code in question this is now using OUString and int for nMaxTextLen in contemporary LibreOffice. It was originally the limited length UniString with nMaxTextLen of type unsigned short so the input of -1 would be considered an unsigned short of 0xFFFF, which was the maximum size of those old strings.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d9a115ae5ba869c1629973e9462d1925812354f0 tdf#145999 -1 was the representation of unlimited cell width It will be available in 7.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/be9211c22d354c489f29f459c22201532aef8da5 tdf#145999 -1 was the representation of unlimited cell width It will be available in 7.3.0.0.beta2. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/b9ad25f5f60eedd1d81a5869938be04cf63627e4 tdf#145999 -1 was the representation of unlimited cell width It will be available in 7.2.5. 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.