Apache OpenOffice (AOO) Bugzilla – Issue 94386
input of numeric values into numeric fields should change color as a warning if the number format is unexpected
Last modified: 2014-05-16 09:29:49 UTC
Open Office version: OOO300m5 System: IBM T60, 1 gig of RAM, 1.66 GHz processor. Steps to reproduce the bug: 1) Open Open Office Impress 2) Insert a table 3) Click on the Table Properties button and then the Font Tab 4) input bar for text size type 1+1 5) Hit the OK button. The font that was put in was 11 instead of getting an error message, or getting the size of 2. I have been able to reproduce this with most symbols (!,@,#,$, and so on) except for the ., which was used for the decimal point.
Jen McCann September 27, 2008 I have been able to reproduce this issue on OpenOffice.org 3.0.0 (300m7, build 9354) I have also found a simpler steps to replicate this issue, as it is not isolated to the Table Properties Font Tab. 1. Open Open Impress 2. Format -> Character 3. Select Font Tab within Character window. 4. Input numerical values with a character in between (as detailed above - e.g., 2+2 or 5*5) 5. Hit 'Enter' or the 'OK' button. 6. Note that the symbols are stripped from the value, such that 2+2 is read as 22, and 5*5 is read as 55. This behaviour is consistent within all Font dialogs within the application, and is also consistent within the Font Toolbar's behaviour. OO Write behaves in the same fashion. I believe this behaviour, while not critical unto itself, could be perceived as an issue to MS Windows users, as MS Office throws an error dialog saying 'that is not a valid number' when this is attempted.
I checked with "Ooo 3.0.0 RC1 Multilingual version ENGLISH UI WIN XP: [OOO300m5 (Build9350)]" and can confirm the reported effect for all OOo applications. OOo will simply ignore non numeric inputs in the UI input panes (except decimal point and units, of course) where numeric inputs are required. An error message should appear instead of simply ignoring the input. Same with "2.4.1 Multilingual version German UI WIN XP: [680m17(Build9310)]" An other way to reproduce: 1. Open CALC 2. Menu 'Format -> Column -> Width' 3. <cntrl>+<a> to mark all input pane contents 4. replace current value ba "1a2" 5. <Enter> expected: Error message "numeric required" actual: "1a2" will be corrected to "12mm" (if "mm" is current unit) without any warning. I doubt that nobody reported this issue before, but I did not find any DUP. @jhilty, @jenmccann Pls. specify your OS!
Reproducible. Reassigned.
cl->pl: looks like a general metric field problem?
I don't even think it's a problem. Do you really want a message box every time you hit a wrong key ? However since there never was a specification how this actually SHOULD behave, let's ask user experience for their take on this.
*** Issue 124440 has been marked as a duplicate of this issue. ***
Due to Bug 124440: OS = ALL; you might find some additional relevant details in that Bug report Still Reproducible with server installation of "AOO 4.1.0-Beta – German UI / German locale - [AOO410m14(Build:9760) - Rev. 1573601 2014-03-03 17:47:48]" on German WIN7 Home Premium (64bit)", own separate user profile. TM seems unintended, back to default.
(In reply to philipp.lohmann from comment #5) > I don't even think it's a problem. Do you really want a message box every > time > you hit a wrong key ? For me: NO!
additional: Format → Paragraph… or Table → Table Properties… or other that can have borders. Open the tab "Borders". Under "Spacing to contents" activate "[X] Synchronise". Type anything into "Left" or "Right" or "Top" or "Bottom". This will result in a "live conversion" of your input in the other fields. Or resize a picture with "[X] Keep ratio". It may be there will be an understanding why the behaviour described in this issue is implemented as it is. For this reason I suggest closing the issue as wont fix.
*** Issue 44212 has been marked as a duplicate of this issue. ***
(In reply to mroe from comment #9) > It may be there will be an understanding why the behaviour described in this > issue is implemented as it is. That's simple to understand: reason was "Don't know better", "had no time to do better", "users did not want better" or similar. (a) Competitors analysis (for Writer Table column width, Calc Column width): (a1) Kingsoft: ignores unallowed characters like wrong decimal separator, alphanumerics, simpy nothing appears in the input line if wrong key has been pressed (a2) SoftMaker FreeOffice: Shows result of key press (unallowed characters appear in input field). But with [ok] or <Enter> a message box "Invalid Number" appears, [ok] in message box marks input field with invalid number (a3) AbiWord (I tested indents): Unallowed characters accepted in input field , but dropped with trailing input filed contents with <Enter> Assuming that most wrong inputs might be wrong decimal separator any other behavior I saw seems smarter than current AOO behavior. (b) My preferred solution: (b1) With <Enter>, [ok] or any other input confirmation ignore wrong character and all trailing input field contents (Similar to Abi Word). (b2) As soon as an unallowed input has been done change contents of input pane to red (or show red background or red frame or similar signal) to show that current input is invalid. (b3) If input has become valid again remove signal color. Example: Column width "2" valid "2 " INvalid "2 c" INvalid "2 cm" valid again You can see how that works with LibO 4.1 menu 'Tools -> Options Language settings -> Languages -> Date recognition pattern string' The current solution was great for the 1990ties, nowadays users expect some more.
Related to or DUP of "Issue 7837 - Insert table function-"rows"accepts non-digit input"
@rainer: Maybe your last sentence in comment 11 (b3) should be for issue 124807?