https://bugs.documentfoundation.org/show_bug.cgi?id=157541

            Bug ID: 157541
           Summary: UI: The Calc Find tool bar functionality is not
                    natural in its search for numbers since if entering
                    11, then the search also finds 111, 1111, etc.
           Product: LibreOffice
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: medium
         Component: Calc
          Assignee: libreoffice-bugs@lists.freedesktop.org
          Reporter: larryg.ki...@gmail.com

Description:
This is a feature modification request.
1. Preferred implementation:
  a. Make the Find tool default to search for the user entered character string
as Whole Number when the character string is entirely made up of numeric digits
with optional sign <-> or <+> for negative or positive number.
    i. Examples: user enters -123 or +123, where in the case of the prefix <->
only -123 is found, and for the prefix <+>, the search finds the digits 123
whether they are prefixed with <+> or not.
  Note: for the remainder of the implementation details, it is assumed any
number, whether whole, or decimal can be entered with sign such that the sign
is handled as discussed for whole number.
  b. If the user enters a digit string with periods or commas without space
characters and no fractional part (they have entered an integer whole number),
then the non-digit delimiters are ignored in the search if not the decimal
point.
    i. Whole number (integer) example: 123.456 where <.> is a thousands
delimiter, or 123,456 where <,> is the thousands delimiter.
  c. If the user enters a decimal number 123.456,23 where <.> is the thousands
delimiter and <,> divides the whole number from its fractional part, then the
search should be equivalent to Whole Cell.
  d. If the user enters a decimal number 123.456,78+ where <.> is the thousands
delimiter and <,> divides the whole number from its fractional part, then the
search will find all strings 123.456,78, including 123.456,789, 123.456,7891,
and so on. If the suffix <+> seems unnatural, then <*> for wild card search
might be more intuitive to the greater user body.
  e. The suffix <?> should be reserved for an "any digit" (or "do not care")
ending digit, <??> for an any pair of ending digits, and so forth. This suffix
character <?> can follow a whole number if the ones digit is any, or but using
<??> the ones and tens are any, and so forth. These suffixes can immediately
follow the decimal for an any fractional part of specified number of digits.

Justification: Calc is primarily for working with data as numbers, not strings.

2. Second choice (simpler) implementation: add a new check box, or replace the
Match Case check box in the Find tool bar with one for Whole Cell.

Justification: Calc is primarily for working with numbers, so a check box for
Match Case in the Find tool bar instead of the more (but not entirely)
intuitive Whole Cell seems a missed opportunity for a very simple ease of use
improvement.

Overall Justification: to search for a given number requires one to click on
the not so obvious Find and Replace Icon in the Find tool bar to bring up the
Fiend and Replace window. One then needs understand that the check box for
Entire Cell is what is needed to find a specified number. The work around in
the Find tool bar is to remember ^51$ will do the same thing, but this is
intended for processing strings not numbers. Nonetheless, there are several
features given the preferred implementation section that are near impossible to
perform in the current implementation of Find in Calc.


Steps to Reproduce:
1. Open Find tool bar.
2. Enter number to search for in text search box such as 11.
3. Press either the up or down buttons.

Actual Results:
Cells are found with 11, 111, 1111, etc.

Expected Results:
Only cells with 11 are found.


Reproducible: Always


User Profile Reset: No

Additional Info:
I am using version 7.6.2.1, build 56f7684011345957bbf33a7ee678afaf4d2ba333.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to