Bug 158426 - Number of SELECTED columns should be limited in Calc data entry form
Summary: Number of SELECTED columns should be limited in Calc data entry form
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Hossein
URL:
Whiteboard: target:24.8.0 target:25.2.0
Keywords:
Depends on:
Blocks: Calc-DataForm
  Show dependency treegraph
 
Reported: 2023-11-29 00:30 UTC by Hossein
Modified: 2024-07-10 11:21 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
more than 32 cols (90.50 KB, image/png)
2024-07-04 13:41 UTC, fpy
Details
more than 32 cols (11.47 KB, application/vnd.oasis.opendocument.spreadsheet)
2024-07-04 13:41 UTC, fpy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hossein 2023-11-29 00:30:15 UTC
Description:
While testing tdf#158211 (a duplicate of tdf#131560), one can face performance problems by doing select all, and then choosing "Data > Form".

Steps to Reproduce:
1. Open Calc
2. Press ctrl+a to select all cells
3. Choose "Data > Form" from menu bar

Actual Results:
LibreOffice hangs for a few minutes. When the dialog box appears at last, it is still unresponsive.

Expected Results:
LibreOffice should respond immediately, as no heavy process is active.


Reproducible: Always


User Profile Reset: No

Additional Info:
The problem is likely because of the excessive number of columns, as they appear in the dialog box as line edit widgets. Limiting the number of possible columns can help avoid this problem.

In MS Excel, when the number of selected columns is too much, a warning message is displayed: "Too many fields in the data form". The maximum number of columns is 32. This is clarified in these links:

https://answers.microsoft.com/en-us/msoffice/forum/all/too-many-fields-in-the-data-form/4ad69e07-524b-40c7-a520-746f4562bc01

https://www.timeatlas.com/excel-data-form
Comment 1 m_a_riosv 2023-11-29 01:34:17 UTC
+1 for the message.
Comment 2 Buovjaga 2023-11-29 06:59:52 UTC
Came up in the live stream and yes, seems like the right thing to do.
Comment 3 Commit Notification 2024-01-29 12:20:06 UTC
Hossein committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/07203b8ed8cc7a392c196b695c9a5c60955b732b

tdf#158426 Limit field columns for data form to 32

It will be available in 24.8.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.
Comment 4 fpy 2024-07-04 13:37:34 UTC
tested on 25.2 RH9, form displays more than 32 cols.

apparently depending on the selected cell, can be 33 (?) or 40 ! 
(see attached).



also note the scrollbar move through *records*, not input boxes, so depending on the display, some columns won't be reachable.
Comment 5 fpy 2024-07-04 13:41:07 UTC
Created attachment 195109 [details]
more than 32 cols
Comment 6 fpy 2024-07-04 13:41:28 UTC
Created attachment 195110 [details]
more than 32 cols
Comment 7 fpy 2024-07-09 06:57:52 UTC
see comment 4.
Comment 8 Hossein 2024-07-09 08:01:03 UTC
(In reply to fpy from comment #7)
> see comment 4.
I don't agree with reopening this issue. The problem described here is completely solved, and it works as expected with the latest LO 25.2 dev master:

Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 6a54d08e6e52623f9769d17d7ea7390052cb275b
CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: CL threaded

The inability to scroll the fields is something else. You can revert this patch, and see that the problem is still there.

$ git revert 07203b8ed8cc7a392c196b695c9a5c60955b732b

I think scrolling problem is a different issue, and a regression with some other commit. I don't remember such an issue after the fix was applied, but I am also building this exact commit to make sure.
Comment 9 Hossein 2024-07-09 09:46:05 UTC
I built the exact commit for this issue, 07203b8ed8cc7a392c196b695c9a5c60955b732b and one commit before that, 07203b8ed8cc7a392c196b695c9a5c60955b732b~1. In both cases, the problem was there. This is the second one:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1e49f469afcbf3d1abec25451117f5f10d3ba825
CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: CL threaded

@fpy
I suggest that you open a new bug report for this specific issue. I think it is a regression, and will need bibisect.
Comment 10 fpy 2024-07-09 10:08:17 UTC
(In reply to Hossein from comment #8)
> as expected 

ok. 
so at least I clarified the title.
we can still have forms with more than 32 boxes when cells are NOT SELECTED (i.e. inferred from contiguous range?).


Help says :
https://help.libreoffice.org/latest/en-US/text/scalc/01/data_form.html

- *Place* the cursor in the header row of the table.
or 
- To reopen the form dialog, *place* the cursor on the header row and open the form.


> I think scrolling problem is a different issue

(but functionally related if we'd be thinking of usable # columns limitation)
following #58062, useful to bbisect that far ago ?
Comment 11 Commit Notification 2024-07-10 11:21:29 UTC
Pierre F committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/help/commit/c2abcb72746a4354ff3e13aa8343c3f123ebc763

misc fix scalc/01/data_form. tdf#158426