Fix für #26: Intern jetzt 4 Nachkommastellen

[susnux]

Intern wird hiermit dann mit 4 Nachkommastellen gearbeitet ( #26) und als default werden 3 angezeigt (ich denke ein guter Kompromiss, 4 brauchen die meisten nicht immer und könnten die Lesbarkeit verringern, 2 hingegen rundet zu stark, 3 scheint ganz gut). Außer dem habe ich in der Doku den Link auf 0.3.1 angepasst.

[ubruhin]

Danke! Ich hätte noch folgende Anmerkung:

Die Änderung vom money format string gefällt mir irgendwie nicht so. Erstens ist es schade, dass Zahlen mit nur 2 Nachkommastellen damit noch eine (unnötige) "0" angehängt bekommen, und bei Zahlen mit 4 Nachkommastellen die letzte Ziffer nicht sichtbar ist. Und Zweitens wird durch diese Änderung das Währungsformat des eingestellten Gebietsschemas (Locale) einfach überschrieben.

Wäre es nicht schöner,

• entweder die Anzeige der Zahlen bei 2 Stellen (bzw. der Anzahl Nachkommastellen des aktiven Gebietsschemas) belassen. Das Textfeld beim eingeben der Zahlen erlaubt ja trotzdem bis zu 4 Nachkommastellen. Einzelpreise unter 0.005 werden dann halt leider als "0.00" angezeigt, aber bei Hochrechnungen stimmt der Endpreis ja trotzdem (also 100*0.001 wird als 0.10 angezeigt).
• oder die Anzahl der Nachkommastellen dynamisch, also je nach darzustellender Zahl, anzupassen. Heisst also, die Anzahl der Nachkommastellen wird für jede darzustellende Zahl ermittelt. Als Minimum wird die Anzahl Stellen, wie sie im aktiven Gebietsschema definiert sind, verwendet, und als Maximum 4 (Limit der Spalte in der Datenbank).

Ich habe gerade noch gesehen, dass bei DigiKey sogar 5 Nachkommastellen verwendet werden. Wenn wir in Part-DB schon die Anzahl Nachkommastellen erhöhen, sollten wir vielleicht besser auch gleich auf 5 Stellen erhöhen?

[susnux]

Danke für dein Feedback! Ich sehe das auch so, vor allem das mit den 5 Nachkommastellen ist kein Problem, da die Gesamtzahl der digits um 3 gestiegen ist (ob 9 oder 8 macht vom Speicherverbrauch keinen unterschied also nimmt man 9) kann man die Nachkommastellen noch um eine erweitern ohne den maximalen Preis zu verringern.

Was das mit dem Format angeht, das sehe ich ein. Ich gucke mal wie man das lösen kann.

[susnux]

Hab die Funktion dementsprechend geändert (wie deine zweite Idee). Sollte kein "money format" gesetzt sein, wird es aus dem aktuellen Gebietsschema "gebaut":

• Hat die Zahl weniger Nachkommastellen als im Gebietsschema festgelegt werden die aus dem GS genommen.
• Ansonsten so viele wie die Zahl Nachkommastellen hat
  • Aber höchstens 5.

PS: Irgendwie ist das komisch, weil die Dateien haben ein gemischtes Zeilenende, mache \n manche \n\r ... Daher der große git diff (ich habe "dos" Format genommen weil das in einer der READMEs stand).