Description: Insert rows allows only 99 new rows, but the input doesn't message that clearly Steps to Reproduce: 1. Open the attached file 2. Right click inside the table 3. Insert -> Rows 4. Type 200 Actual Results: 99 are inserted Expected Results: Maybe increase toe row limit a bit (99 isn't that much?) However the main point some indication it isn't allowed.. yes it does, but have to change above below Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: ed4f610f4a3de12016f8308a17b6ad4f86e9d67a CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 165467 [details] Example file
Also in 4.4.7.2
@Caolan Can the input be limited or corrected without leaving the spin box (this was already a topic on table dialog). Something about not designed that way.. Or any other idea how to make it bit more obvious from DEV point of view? Limiting the input to 2 digits? However find 99 slightly low, but might be me. Or increasing the row limit a bit would mask it pretty well (without fiddling with the rest) Of course this might be a UX question..
"Can the input be limited or corrected without leaving the spin box" As far as I understand LibreOffice is not unusual in this SpinButton behavior. That's what nearly everyone does, update on losing focus. In the case that we're using gtk widgets instead of the vcl ones we don't have fine control over that aspect of their behavior anyway[1]. I could imagine adding a key combo to update the current SpinButton that focus is in (ctrl+space or something), but there isn't, as far as I know, a commonly known key combo for the concept. (We have about ~600 SpinButtons like this so something like adding labels to indicate the limits seems impracticable and undesirable) "However find 99 slightly low, but might be me." FWIW, it seems on a quick look that MSWord (2013) and Google Docs allow the user to insert just 1 row above/below so 99 looks generous compared to that (With the default font 100 rows gives a table that spans about three pages). But its no biggy to change the max: https://gerrit.libreoffice.org/c/core/+/102959 [1] Though it would be neat if gtk did something like change the border color from the default blue to red if the current entered text would result in a number out of range.
(In reply to Caolán McNamara from comment #4) > [1] Though it would be neat if gtk did something like change the border > color from the default blue to red if the current entered text would result > in a number out of range.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/429d4e1c70c71e898de293647c7623303ffe960b tdf#136729 raise insert row/col from 99 to 200 It will be available in 7.1.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.
I'll call this resolved as I think that's as much as we can do here
(In reply to Caolán McNamara from comment #7) > I'll call this resolved as I think that's as much as we can do here We should prevent the spinner from accepting input beyond the value. If it can't be set in the ui file (cui/uiconfig/ui/insertrowcolumn.ui) I guess set_range(min, max) would do the trick (cui/source/dialogs/insrc.cxx).
re comment #8, we do limit the range and it is set in the .ui. Using the up and down buttons will clip to those limits. The issue is with the entry of free text and that the "being-edited" text is not crystallized to a value until a spinbutton loses focus at which point the text is parsed and converted to a number and then that number is clipped to the legal range. So an entry of e.g. the text "1000" is not turned into an integer of 1000 and then clipped to the max of 200 until the spinbutton loses focus and that is where I contend there is little more that can be done.
(In reply to Caolán McNamara from comment #9) > issue is with the entry of free text.. Do we have a ticket about this issue? IIRC there are some hackish solutions around but in fact it should be solved centrally.
I'm going to put this back to resolved as per my arguments up to comment #7. IMO no further action is needed.
Verified. Fixed in Version: 7.1.0.0.alpha0+ Build ID: f21f3d094cfb495c89dfb0a23ecb061ef1a2178e CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded