Description: Calc: Print range added to "Named Ranges and Expressions" doesn't show up in the print ranges dialogue if row number has more than 6 digits. If it has 6 digits max it shows up. Steps to Reproduce: 1. Create empty sheet. 2. Sheet--Named Ranges and Expressions--Manage 3. Create a new range covering $A$1:$A$9999999 and define it as a print range by ticking "Print range" under "Range options". 4. Open Format--Print Ranges--Edit and click at the dropdown menu for adding a range. Actual Results: The range doesn't show up in the list of named print ranges. Expected Results: The range should show up as a print range, or, if 7 digits row numbers are too much too handle, I'd like an error message when I try to define it so I know. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.4.6.2 Build ID: 1:6.4.6-0ubuntu0.20.04.1 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: sv-SE (sv_SE.UTF-8); UI-Language: en-GB Calc: threaded
It's not the number of digits that are relevant. It works with 1048576 rows max, anything over that will not work.
Why do you expect a print range exceeding the maximum number of rows (2^20 = 1048576 ) in a calc spreadsheet (neglecting experimental feature "large sheets" in version 7.0 and later) to work? From my perspective this is not a bug, though it is disputable whether there should be a warning about an out-of-boundary named range.
(In reply to Uwe Auer from comment #2) > Why do you expect a print range exceeding the maximum number of rows (2^20 = > 1048576 > ) in a calc spreadsheet (neglecting experimental feature "large sheets" in > version 7.0 and later) to work? From my perspective this is not a bug, > though it is disputable whether there should be a warning about an > out-of-boundary named range. What makes it a bug is that there's no error message. If I do something that the program will ignore or that will make the program unstable, I expect to get noticed as to why this is so. This is the behaviour in other cases: For example if I try to SUM a too large area, maybe by a writing typo etc, I get a #NAME? in the cell to tell me that something is wrong with the range.
The possibility to enter wrong values need to be checked / prohibited in the UI. Rather than an interrupting message box, the input field should show the error by a different control background via set_message_type(weld::EntryMessageType::Error) and disable the confirmatory action ie. the Okay button.
Dear alex, 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
Created attachment 192950 [details] Edit print ranges dialog error message
Created attachment 192951 [details] Manage Names error message
Should unify the two dialogs or just check the range and show an error message as a tooltip like comment 4 suggests?
(In reply to Andreas Heinisch from comment #8) > ...message as a tooltip like comment 4 suggests Comment 4 recommends to disable the Okay button and to give feedback on the control. The static tip on the Manage Names dialog might be a good idea in this case since the restriction to just letters is unclear. Btw, if you enter "a1", for example, in the Define Name dialog, the result is exactly as recommended. And when it comes to the explanation later: "a1" is not accepted because of the number but the length, which is not noted in the text. Easy to get from just changing the string.
(In reply to Andreas Heinisch from comment #7) > Created attachment 192951 [details] > Manage Names error message This shows the current implementation of this dialog without the "Invalid sheet reference" in the error message. My suggestion is to remove the current error line and show both error messages as a tooltip including weld::EntryMessageType::Error on the correct input field.
(In reply to Andreas Heinisch from comment #10) > My suggestion is to remove the current error line and show both error > messages as a tooltip including weld::EntryMessageType::Error on the correct > input field. A tooltip is only useful for a user that knows to look for it by hovering on the relevant UI artifact. If a user introduces an invalid/unacceptable value/name/whatever in a field, the hints have to be better, with clear wording (for users that don't know the restrictions beforehand), and clearly seen. If, instead, a user that has attempted an unacceptable value has to _imagine_ that a tooltip exists (somewhere) that would give the adequate hint of what was wrong, then discover-ability is not improved. To improve the situation, whichever potential suggestion has to start by placing yourself in the place/mind of a user that doesn't know beforehand the requirements for these fields, and has no idea that a tooltip exists. Unless there is some kind of "?" icon (or similar), how a user would find the answer in such tooltip, when he does not know of its existence beforehand? Isn't a direct hint text shown directly on the dialog easier to discover by such user?
You are correct, so you would suggest to concatenate the error messages in the line above?
(In reply to ady from comment #11) > (In reply to Andreas Heinisch from comment #10) > > > My suggestion is to remove the current error line and show both error > > messages as a tooltip including weld::EntryMessageType::Error on the correct > > input field. > > > A tooltip is only useful for a user that knows to look for it by hovering on > the relevant UI artifact. > > If a user introduces an invalid/unacceptable value/name/whatever in a field, > the hints have to be better, with clear wording (for users that don't know > the restrictions beforehand), and clearly seen. > > If, instead, a user that has attempted an unacceptable value has to > _imagine_ that a tooltip exists (somewhere) that would give the adequate > hint of what was wrong, then discover-ability is not improved. > > To improve the situation, whichever potential suggestion has to start by > placing yourself in the place/mind of a user that doesn't know beforehand > the requirements for these fields, and has no idea that a tooltip exists. > > Unless there is some kind of "?" icon (or similar), how a user would find > the answer in such tooltip, when he does not know of its existence > beforehand? Isn't a direct hint text shown directly on the dialog easier to > discover by such user? The fields would be red indicating clearly that there must be an error somewhere. As I user I would imagine that you move to that field where it states which error is there.
Created attachment 192961 [details] Current state in the define name dialog
The _red_ background in a field that needs introduction of data is frequently a source of complaints from users. For some reason, the contrast between the text and the red background is not good enough in order to comfortably read the content of the field, which is a problem when, for instance, there is a typo and the user just needs to clearly read and identify the typo he just introduced a moment before. Instead of the red background, I wonder whether there is a way to achieve a red slightly thicker border on the field (but without affecting any other artifact of the window/screen). Between changing the color of the border and its thickness, it should give a visual cue without affecting the normal contrast between the font color (within the field) and its background. Additionally, such border color might need to be different (i.e. another color) under certain circumstances, such as dark mode or a "reddish" theme. As for the tooltip, it should never overlap the field itself (so its content can still be clearly read). Although the screenshot in comment 14 shows it in such way, I am mentioning it anyway (for screen resolution, or whichever other factor that might affect its placement). I am still unsure what exactly would trigger the tooltip to be displayed. If a user must point the mouse over the field in order for the tooltip to show up, I'm still not convinced it would be enough. All these details are factors, IMHO. Regarding where the hint message should be better placed (direct text on some area within the dialogue window, tooltip, some other method, and where any of these should be placed), I'll leave that for the UX experts (e.g. Heiko) to opine.
An alternative to the border thickness change I mentioned in my prior comment could be a border "style" change. For instance, from the normal border to "dotted", using the same thickness as the normal border of the relevant field.
At the moment I just added an info text which is the same text used in the print range dialog: https://gerrit.libreoffice.org/c/core/+/164434 I will disable the OK button as well if there is an error.
(In reply to ady from comment #15) > The _red_ background in a field that needs introduction of data is > frequently a source of complaints from users. Gtk3 uses its own method [1] while other VCLs draw black on 0xffff38 and 0xff3838 [2], the latter with a contrast of 5.87:1. No objection to make this comply with WCAG AAA. But it's a different topic, and I'd prefer to add themed feedback for the various frameworks. [1] vcl/unx/gtk3/gtkinst.cxx set_widget_css_message_type(), set_entry_message_type() [2] vcl/source/app/salvtables.cxx set_message_type()