Issue 2056 - Erroneous change in font size value for an expression input.
Summary: Erroneous change in font size value for an expression input.
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: 638
Hardware: PC Windows 2000
: P3 Trivial (vote)
Target Milestone: AOO PleaseHelp
Assignee: AOO issues mailing list
QA Contact:
: 7837 (view as issue list)
Depends on:
Reported: 2001-10-29 15:35 UTC by Unknown
Modified: 2017-05-20 10:45 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Unknown 2001-10-29 15:35:07 UTC
When a mathematical expression is given as an input to font size, then the new 
font size value is computed erroneously. The operators and any other alphabets 
in the expression are ignored and the remaining integers of the input are 
concatenated and the concatenated value is treated as an input.

Steps to Reproduce the defect:
1. Drag and drop a text box.
2. Type a text (say, "abcd") and select it .
3. Enter a mathematical expression to the font size combo box (say, 10 * 3). 
4. Hit <enter> button.

Actual Result:
The font size of the selected letters was changed to 103.

Expected Result:
Error message "Invalid Input"

Build date and Platform:
10/1/01 build Windows 2000 Service Pack2.

Additional build and Platform:
10/24/01 build Windows Me.

Follow up Tests:
Enter any text to font size combo box(say, 10a3 ). All alphabets and operators 
(if any) are ignored and the new font size value is the concatenation of 
remaining integers. If no integers present, then the previous font size value 
is restored.
Comment 1 bettina.haberer 2001-11-12 15:18:30 UTC
We should avoid the possibility to add other characters except 
numeric values and comma/point as decimal place.
Comment 2 malte_timmermann 2001-11-30 09:23:00 UTC
OK, must check for valid input...
Comment 3 malte_timmermann 2002-12-19 17:12:33 UTC
From i1556
MetricFields act strange when they are set to use a comma as decimal 
separator and when a dot is inserted. 
The cursor moves over the displayed comma but GetValue() 
returns the value with the dot ignored (and cut to the maximum if 
necessary). In other words 1.10 changes to 110.  

Does it make sense to accept an "." at all, if "," is the decimal 
separator ?

Not sure... What about 1.000,00 ?
=> Can't do it.
Comment 4 malte_timmermann 2003-01-28 11:15:53 UTC
Nothing for OOo 1.1, see also 2295
Comment 5 malte_timmermann 2003-02-03 16:47:23 UTC
MT: Problem is the #8166#

*** This issue has been marked as a duplicate of 8166 ***
Comment 6 malte_timmermann 2003-02-03 16:49:59 UTC
Marked wrong task as double...
Comment 7 malte_timmermann 2003-02-03 16:50:32 UTC
Comment 8 malte_timmermann 2003-08-07 09:02:23 UTC
*** Issue 7837 has been marked as a duplicate of this issue. ***
Comment 9 malte_timmermann 2003-08-07 09:03:01 UTC
See also #7837#...
Comment 10 malte_timmermann 2005-02-23 16:49:31 UTC
MT->SSA: VCL Fields again...
Comment 11 stephan_schaefer 2005-12-02 11:21:27 UTC
SSA: reassign to HDU, see also issue 2295
Comment 12 2006-01-06 11:49:17 UTC
Comment 13 Rainer Bielefeld 2014-05-09 05:46:23 UTC
This one has a much to special summary for a general problem.

Status and Assignee back due to facts

I think the best description an most reesearch we have in "Issue 94386 - In input panes for numeric values, alphanumerics will be removed without warning"
Comment 14 Marcus 2017-05-20 10:45:03 UTC
Reset the assignee to the default "".