Description: When editing the properties of a Form, the property window is too narrow and does not display all controls Especially buttons on the right are hidden and as a newbie to Base, I did not understand that the problem was only about enlarging the window. Steps to Reproduce: 1. Create a form with a sub form 2. Edit properties of the sub form Actual Results: property window does not display buttons on the right Expected Results: property windows should be large enough to display all controls Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: fr Module: FormDesign [Information guessed from browser] OS: Windows (All) OS is 64bit: no
Created attachment 170488 [details] screenshot of sub form property window
I couldn't reproduce this under OpenSUSE 15.2 64bit rpm Linux with LO 7.0.5.2, 7.1.5.2 and 7.2.2.2 and the internal HSQLDB. But: I got the same behavior together with MariaDB and direct connection. The length of the tables has been too big for the listbox and the listbox for the tables expands the whole content in the dialog - except the dialog itself. Then I excluded the system tables of MariaDB by Tools → Table Filter… and the dialog will be opened without any (visual) problem. 1. Which database do you use? 2. Is there any field in the form properties dialog, which seems to be expanded too much by the internal content?
I can confirm this on macOS. Version: 7.2.1.2 / LibreOffice Community Build ID: 87b77fad49947c1441b67c559c339af8f3517e22 CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded Using a mysqldb backend datasource, and a form + subform that connects to that datasource. For example, selecting a grid control, choosing control properties from the context menu of the selected control, displays a default window for which the "Events" tab fields are systematically truncated on the right hand side, whereas the "General" tab shows everything in full width. cf. enclosed screenshot. It appears that the multi-tab properties dialog only adapts the size of the UI widgets contained in it for the first tab. I have the feeling though, that his problem has been around a long time already. Probably one for the UX team.
Created attachment 175751 [details] Screenshot of default width in 2nd tab of multitab dialog
(In reply to Alex Thurgood from comment #3) > It appears that the multi-tab properties dialog only adapts the size of the > UI widgets contained in it for the first tab. I have the feeling though, > that his problem has been around a long time already. Actually, I can so far only reproduce this with the "Events" tab, both the "General" and "Data" display UI widgets of the correct width to fit the default properties window size.
Created attachment 175753 [details] Open the form in the database for editing. Go to form properties → data. Problem could be seen in the little attached database. Open the database. Open the form for editing. Mark a control. Right mouse click → Form Properties … Switch to tab "Data", if it isn't shown directly. Width of list box for "Content" is too wide. Dialog is too small for it. Close the form. Go to Tools → Table Filter … Deselect the table "much_too_much …" Save the database file. Close it and restart. Open the form for editing, open form properties → dialog will appear with enough width. Width of listboxes shouldn't expand together with the length of the content inside the box. It should show the whole content only when listbox will be opened.
This all works fine with LO 6.4.7.2 on OpenSUSE 15.2 64bit rpm Linux. Fails with introducing of LO 7.0. So it is a regression.
@ Alex: If we would expand the dialog to show the whole content of tab "Event" the width of the dialog will expand too much. You are right: This never worked and I won't prefer it for something like a little Netbook.
Dear frank.derville, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bibisected with linux-64-7.0 with gtk3 UI and steps from comment 6 to 1efeb17837c22499f00299c033ae59ba3910f7d7 weld Property Browser The bad state for me has the scrollbar overlaid on the right side of the widgets while in the earlier state there is a clear hygienic separation. On the other hand, I don't see any issue on Windows or gen or kf6 with the steps from comment 6 (in master). Not sure, if the overlaid look with gtk3 can be called bad at all, but let's ask Caolán what he thinks.
Created attachment 202355 [details] same odb but with all table enabled by default
I think the demo of comment #6 has the offending table deselected by default, so attached with it selected by default to make reproducing the substantive issue easier. I believe https://gerrit.libreoffice.org/c/core/+/189808 should take care of that. The gtk overlay scrollbar is just what gtk does with scrollbars by default, I'm happy enough with them.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9fc99321c11202aa92fe6b932c5afd38ffe81e31 Resolves: tdf#141033 make combobox max width the same as editboxes It will be available in 26.2.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-25-8": https://git.libreoffice.org/core/commit/4536c3d4230c0c52a0d05fb2e184b38b892bb385 Resolves: tdf#141033 make combobox max width the same as editboxes It will be available in 25.8.1. 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.