Bug 140394 - There should be a warning, if print range would exceed the maximum number of rows
Summary: There should be a warning, if print range would exceed the maximum number of ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.4.6.2 release
Hardware: All All
: medium normal
Assignee: Andreas Heinisch
URL:
Whiteboard: target:25.2.0
Keywords:
Depends on:
Blocks: Print-Range
  Show dependency treegraph
 
Reported: 2021-02-13 17:20 UTC by alex
Modified: 2024-08-23 12:54 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Edit print ranges dialog error message (11.84 KB, image/png)
2024-03-04 23:45 UTC, Andreas Heinisch
Details
Manage Names error message (14.52 KB, image/png)
2024-03-04 23:45 UTC, Andreas Heinisch
Details
Current state in the define name dialog (13.32 KB, image/png)
2024-03-05 12:32 UTC, Andreas Heinisch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description alex 2021-02-13 17:20:28 UTC
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
Comment 1 alex 2021-02-13 17:34:33 UTC
It's not the number of digits that are relevant. It works with 1048576 rows max, anything over that will not work.
Comment 2 [REDACTED] 2021-02-13 23:18:32 UTC
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.
Comment 3 alex 2021-02-14 09:50:26 UTC
(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.
Comment 4 Heiko Tietze 2022-02-03 11:28:12 UTC
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.
Comment 5 QA Administrators 2024-02-04 03:14:08 UTC Comment hidden (obsolete)
Comment 6 Andreas Heinisch 2024-03-04 23:45:21 UTC
Created attachment 192950 [details]
Edit print ranges dialog error message
Comment 7 Andreas Heinisch 2024-03-04 23:45:50 UTC
Created attachment 192951 [details]
Manage Names error message
Comment 8 Andreas Heinisch 2024-03-04 23:47:20 UTC
Should unify the two dialogs or just check the range and show an error message as a tooltip like comment 4 suggests?
Comment 9 Heiko Tietze 2024-03-05 10:19:32 UTC
(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.
Comment 10 Andreas Heinisch 2024-03-05 11:07:38 UTC
(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.
Comment 11 ady 2024-03-05 11:45:47 UTC
(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?
Comment 12 Andreas Heinisch 2024-03-05 11:54:58 UTC
You are correct, so you would suggest to concatenate the error messages in the line above?
Comment 13 Andreas Heinisch 2024-03-05 12:00:02 UTC
(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.
Comment 14 Andreas Heinisch 2024-03-05 12:32:55 UTC
Created attachment 192961 [details]
Current state in the define name dialog
Comment 15 ady 2024-03-05 19:59:43 UTC
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.
Comment 16 ady 2024-03-05 20:41:22 UTC
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.
Comment 17 Andreas Heinisch 2024-03-05 21:19:13 UTC
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.
Comment 18 Heiko Tietze 2024-03-06 08:45:33 UTC
(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()
Comment 19 Commit Notification 2024-08-23 12:52:59 UTC
Andreas Heinisch committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/bee09884a65013ab01584c71f70b37c99900a1bf

tdf#140394 - Manage names dialog: check if formula is a valid print range

It will be available in 25.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.
Comment 20 Andreas Heinisch 2024-08-23 12:54:11 UTC
The test is in the previous gerrit patches. No idea how to get it work without interfering with other tests.