LibreOffice-Forum

Hallo allerseits!
Vermutlich habe ich irgendwo etwas geändert, was mich jetzt extrem nervt, und ich kriegs nicht weg:
Wenn ich in einer neuen CALC-Tabelle in einer neuen Zelle eine Zahl eintippe, wird sie nur zum Teil erkannt, je nach Format.
Anscheinend spielt mir die automatische Zahlenerkennung einen Streich. Hier sind ein paar Beispiele:
Was ich eingebe: 1 ==> wie es erkannt wird: OK, als Zahl erkannt (rechtsbündig, korrekte Zahl)
12 ==> OK
123 ==> OK
1.2 ==> TEXT (linksbündig wie Text, in einer Formel gibts einen Fehler)
12.3 ==> TEXT
123.4 ==> OK
01.2 ==> TEXT
001.2 ==> OK

Die letzten 4 Beispiele zeigen die "Regel": sobald ein Dezimalpunkt vorhanden ist, müssen vor dem Punkt mindestens 3 Stellen eingegeben werden, damit die Eingabe als Zahl erkannt wird.
Kann mir bitte jemand erklären, ob das ein normales Verhalten ist ( ), oder WO ich das kaputtgemacht habe ( )?

Vielen Dank im voraus.

Kann ich nicht so nachvollziehen:

123.4 ==> "nicht ok"
1.234 ==> "OK"

Der Dezimalpunkt gehört nicht in die Eingabe! Nimm ordentlich deutsch das Komma.

In Excel senst er bei gültigen Dezimalpunkteingaben daraus ein Datum:

1.2 = 1. Februar

ITOpa hat geschrieben: ↑

Mo 7. Mai 2018, 15:25

Die letzten 4 Beispiele zeigen die "Regel": sobald ein Dezimalpunkt vorhanden ist, müssen vor dem Punkt mindestens 3 Stellen eingegeben werden, damit die Eingabe als Zahl erkannt wird.

Dein Calc ist in den Optionen auf deutsch eingestellt. In Deutschland aber gibt es keinen Dezimalpunkt, sondern nur ein Dezimalkomma. Der Punkt dient nur als Gruppentrenner. So erkennt es auch Calc. 1.2 ist nach dieser Regel Text. 001. könnte eine Zahl sein mit dem Gruppierungszeichen und wird deshalb als Zahl erkannt.

Das mit der Zahlenerkennung ist mitunter verwirrend. Deshalb habe ich bereits vor vielen Jahren diesem Thema eine ausführliche Erläuterung gewidmet. Siehe http://www.ooowiki.de/ZahlenerkennungInCalc.html

Ja so ist das halt mit der Zahlenerkennung! Meine Zusammenfassung könnte dir da sicher auch nicht schaden.

Lupo hat geschrieben: ↑

Mo 7. Mai 2018, 17:16

Kann ich nicht so nachvollziehen:

123.4 ==> "nicht ok"
1.234 ==> "OK"

123.4 zeigt nach dem Punkt keine Dreiergruppe. Deshalb wird der Punkt auch nicht als Dezimalzeichen interpretiert. Folglich TEXT.
1.234 hat eine Dreiergruppe nach dem Punkt. Deshalb wird der Punkt als Gruppierungspunkt interpretiert. Folglich ZAHL

Lupo hat geschrieben:In Excel senst er bei gültigen Dezimalpunkteingaben daraus ein Datum:

1.2 = 1. Februar

Das macht Calc auch (aber Achtung! http://de.openoffice.info/viewtopic.php ... 49#p235849)!

Näheres zum Erkennungsmodus: http://www.ooowiki.de/ZahlenerkennungIn ... m_und_Zeit

Danke Lupo und Rocko für die Hinweise, die mich an die kritische Stelle geführt haben.

Mit "Ordentlich Deutsch" kann ich nur bedingt dienen, da ich einem anderen Standard fröne:
Benutzeroberfläche: Standard - Deutsch (Deutschland)
Gebietsschema: Standard - Deutsch (Schweiz)
Dezimaltrennzeichen: Entsprechend Gebietsschema (.)
(Übrigens wäre das Tausendertrennzeichen unter Format -- Zellen -- Dezimalzahl der Apostroph ' (Hochkomma) )
Standardsprachen der Dokumente:
Westlich: Standard - Deutsch (Schweiz)

Jetzt kommts...
HIER habe ich tatsächlich etwas geändert, nämlich bei
Datumserkennungsmuster: D.M.Y;D.M.;D.

Bei genauer Betrachtung dieses Musters denke ich zwar, dass es eine Zahleneingabe wie 1.2 eigentlich nicht stören sollte (das würde sonst D.M entsprechen, was aber nicht da ist).
Versuchshalber habe ich das Muster geändert zu D.M.Y;D.M. und tatsächlich wird jetzt die Eingabe 1.2 einwandfrei erkannt!
Ich sehe natürlich, dass meine Einstellung mit Punkt und Punkt für beide Zwecke das Problem zwar auslöst -- aber verursachen sollte sie es nicht, weil das Datumsmuster nicht greifen sollte. also, meines Erachtens ist das nicht korrekt.

Rocko hat geschrieben: ↑

Mo 7. Mai 2018, 17:37

Ja so ist das halt mit der Zahlenerkennung! Meine Zusammenfassung könnte dir da sicher auch nicht schaden.

Lupo hat geschrieben: ↑

Mo 7. Mai 2018, 17:16

Kann ich nicht so nachvollziehen:

123.4 ==> "nicht ok"
1.234 ==> "OK"

123.4 zeigt nach dem Punkt keine Dreiergruppe. Deshalb wird der Punkt auch nicht als Dezimalzeichen interpretiert. Folglich TEXT.
1.234 hat eine Dreiergruppe nach dem Punkt. Deshalb wird der Punkt als Gruppierungspunkt interpretiert. Folglich ZAHL

Ich weiß das wohl alles, Rocko. Ich schrieb, dass ich den Fehler des TE nicht nachvollziehen konnte (eben WEGEN der notwendigen Dreiergruppe). Ich schrieb nicht, dass ich das Problem nicht verstünde.

Jetzt bin ich nicht sicher, wie ich das interpretieren soll (haben sich unsere Beiträge evt. überlappt?)...
- Die Dreiergruppe, die es bei mir braucht, muss VOR dem Dezimalzeichen sein -- dahinter ists egal.
Also für mich ganz klar, nur xxx.y wird erkannt, nicht aber x.yyy .
- Zahlenerkennung TROTZ Punkt ist nicht das Thema, da in meinem Schweizer Schema der Punkt korrekt ist.

Lupo hat geschrieben: ↑

Mo 7. Mai 2018, 18:06

Ich weiß das wohl alles, Rocko. Ich schrieb, dass ich den Fehler des TE nicht nachvollziehen konnte (eben WEGEN der notwendigen Dreiergruppe). Ich schrieb nicht, dass ich das Problem nicht verstünde.

Was sollte dann der lapidare Hinweis,

Lupo hat geschrieben:In Excel senst er bei gültigen Dezimalpunkteingaben daraus ein Datum:

1.2 = 1. Februar

wenn das doch auch in Calc funktioniert?

Tut es nicht. Zwischen 1.2 und 1.2. ist ein elementarer Unterschied, denn Excel senst nur ohne 2. Punkt. Bzw. LO nur mit.

Lupo hat geschrieben: ↑

Mo 7. Mai 2018, 19:52

Tut es nicht. Zwischen 1.2 und 1.2. ist ein elementarer Unterschied, denn Excel senst nur ohne 2. Punkt. Bzw. LO nur mit.

Behauptest du nur oder prüfst du deine Aussagen auch?

In LO 4.4.4.3 und in AOO 4.1.4 erhalte ich dasselbe Ergebnis:

Links als Text (mit Hochkomma), rechts zur Zahlenerkennung eingegeben. Was Excel macht interessiert mich nicht. LO jedenfalls nicht "nur mit".