Seit Windows 11 und/oder Version LibreOffice Version 24 habe ich das Problem, dass in schmalen Zellen eingegebene Zahlen und Rechenergebnisse mit mehreren Nachkommastellen als ### angezeigt werden, obwohl im Zellenformat keine Nachkommastellen angegeben sind. Das war vorher - d.h. unter Windows 10 mit LibreOffice Version 7 - anders. Wenn ein gerundetes Ergebnis in die Zelle gepasst hat, wurden genau so viele Stellen angezeigt, wie bei der Spaltenbreite möglich. Konnte die Zahl auch mit Runden nicht in der Spaltenbreite anzeigt werden, so erschien ###. Durch Ändern der Spaltenbreite konnte man also die Anzahl der Nachkommstellen vergrößern und verringern, außer die Zahl war zu groß. Gibt es dieses Verhalten noch und ist es durch eine spezielle Einstellung zu erreichen? Wenn ja, wo und wie?
Seit über 30 Jahren zeigen Tabellenkalkulationen den Gartenzaun anstelle einer unvollständigen Zahl, wenn die Spalte für die vollständige Darstellung des formatierten Zahlenwertes zu schmal ist. Bei Textwerten überlappt der Text leere Nachbarzellen oder wird abgeschnitten.
Im Falle einer konstanten Zahl wird unabhängig von der Formatierung immer der wahre unformatierte Zahlenwert in der Eingabezeile angezeigt.
Du musst einfach nur die Spalte breiter machen, am einfachsten per Doppelklick auf den rechten Rand des grauen Spaltenkopfes.
Ich habe herausgefunden, woran es liegt. Bei Zoom 100% ist das Verhalten wie von mir gewünscht, bei Zoom 90% werden die ### angezeigt.
Ich habe dann noch andere Zoom-Stufen ausprobiert und folgendes herausgefunden:
###: 60%,90%,120%,160%
Ok: 65%,75%,80%,85%,95%,100%,110%,130%,140%,150%,170%,180%,190%,200%
Vielleicht hilft das ja, um den Fehler einzukreisen.
Es ist also wahrscheinlich, dass es mit Windows11 und Version 24 gar nichts zu tun hat.
Bei mir passiert das nicht, egal auf welcher Zoomstufe!
Version: 24.2.4.2 (X86_64) / LibreOffice Community
Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded
Es bedarf noch weiterer Nebenbedingungen: Spaltenbreite 2,26 cm, Schriftart Liberation Sans 10pt.
Ja, genau!
Falls deine Zelle eine Formel enthält, solltest du diese Berechnung mal offenlegen.
Der Wert ist offenbar auch entscheidend. Bei mir ist es =247/210
Mit diesem Wert habe ich bei Spaltenbreite 1,85cm, Schriftart Times New Roman 10pt und Zoom-Faktor 100% das gleiche Problem.
Ja, jetzt kann ich es nachvollziehen.
Bleibt dir wohl nur die Spaltenbreite wie von @Villeroy vorgeschlagen anzupassen.
Macht es Sinn, das bei Bugzilla als Fehler einzutragen?
Die Anmerkung “better file a dupe than give up” hat mich veranlasst, es doch einzutragen.
Der Fehlercode stimmt nicht, da der Wert auf weniger Stellen gerundet ja hineinpasst.
Warum aktivierst Du nicht einfach in der Zellvorlage Standard im
Register Ausrichtung: ☒ An Zellgröße anpassen?
So der stimmt dann also auch nicht bei Excel und wer weiß noch, wo nicht?
An Zellgröße anpassen hat bei bugzilla auch jemand vorgeschlagen. Das macht die Schrift unlesbar klein.
Der Fehlercode stimmt, aber er dürfte in diesem Fall nicht zutreffen. Ich hab noch zwei Screenshots, die zeigen, was ich meine - derselbe Inhalt, oben 100%, unten 90%.
Diesen Fehler meinte ich.
Die Ursache des Fehlers ist jetzt nachvollzogen, es handelt sich um den Vergleich einer Summe von gerundeten Werten mit einer gerundeten Summe von float-Werten.
Ich meine, eine Fehlerbehebung zur Verfügung stellen zu können. Es handelt sich ausschließlich um die Datei output2.cxx. Da ich aber keine geeignete Entwicklungsumgebung habe, kann ich noch nicht einmal compilieren.
Wem kann ich die Datei output2.cxx (revision 8b23abac) - OpenGrok cross reference for /core/sc/source/ui/view/output2.cxx zusenden, damit er sie überprüfen und in das Projekt einbauen kann? Meine Version setzt auf Revision 8b23abac auf.
@piteo : Warum meldest Du das nicht beim Bug: Bug 161974. Da bist Du doch auch eingetragen.
Wie das dort mit der Code-Weitergabe läuft weiss ich so auch nicht.
Die Definition in The Document Foundation Wiki : “a bug is something that makes the software behave in a way that a reasonable user would not want it to behave”.
Welcher vernünftige Benutzer wünscht, dass sich die Software mal so und mal so verhält, ohne ahnen zu können, wie sie sich jetzt gleich verhalten wird?
Ich habe das hier einmal getestet:
=247/210 in A1 eingetragen.
Die Zelle zusammengeschoben.
Wert wird gerundet.
Die Zelle auseinandergezogen.
Wert wird mit entsprechend mehr Nachkommastellen dargestellt.
Auf 90% gegangen.
Wert wird als ### dargestellt.
Das passiert auch bei 60%, nicht aber bei den Zwischenstufen.
Testversion 24.2.4.2 unter OpenSUSE Linux.
Dann den gleichen Test mit LO 7.4.7.2 auf dem gleichen System.
Dort läuft der Zomm einwandfrei.
Das ist eindeutig eine Regression.
Vielen, vielen Dank!
Ich glaubte schon, ich sei verrückt, als ich den Quellcode von 7.4.7.2 durchforstet habe und den Fehler nicht nachvollziehen konnte.
Vielleicht bekomme ich ja den Quellcode von 24.2.4.2, um dort die Fehlerursache suchen zu können.