wenn ich ein zusätzliches Attribut für Wertpapiere vom Feldtyp “Betrag (einfach)” erstelle, sieht der 1’000er Apostroph zwar sehr schön aus (und ist zum lesen sehr praktisch) aber beim Editieren macht der leider Probleme:
Ich habe mittlerweile mehrere diese Felder und muss bei jedem Editieren des Wertpapiers bei allen diesen Feldern den Apostroph rauslöschen (1’234 → 1234) damit ich die Änderungen wieder speichern kann.
Allenfalls ist das ein issue mit der Länderspezifischen Einstellung (ich verwende de_CH)
ich nutze Portfolio Performance zwar nicht in der Sprache/Zahlendarstellung de_Ch, konnte das Problem mit dem Hinweis zur ungültigen Zahl im Wertpapierbearbeitungsfenster jedoch nachstellen. Es tritt übrigens auch bei de_LI auf.
Solange dies noch nicht behoben ist, kannst du - falls du viele Anpassungen an Wertpapiereinträgen durchführen musst - kurzzeitig die Zahlendarstellung ändern, die Bearbeitung der Wertpapiere durchführen und anschließend die Zahlendarstellung wieder zurückwechseln. Noch keine Lösung, aber es erspart trotzdem etwas Arbeit/Zeit, sofern man viele Wertpapiereinträge anpassen möchte
Ich schau mir das gerade an, hätte zum Rückversichern aber gerne ein paar weitere Datenpunkte. Das Zeichen für die Tausendergruppierung ist nicht das Hochkomma ('), sondern ein Aphostroph (’), richtig? Versucht mal bitte ein Limit zu definieren. Hier müsste es die gleiche Fehlermeldung geben. Gibt man dann statt eines Apostrophs ein Hochkomma an, dürfte die Prüfung durchgehen, dann aber im weiteren Verlauf wieder scheitern.
ich gebe den Apostroph NICHT manuell ein! Das macht Portfoliomanager automatisch!
Ich schreib nur 1234 und raus kommt 1’234
bei der Fehlermeldung, welch ich oben gepostet habe muss ich nur den Apostoph löschen, dann kann ich das speichern
So wie ich @pderpan im post davor verstanden habe, kann er das mit umstellen der Settings reproduzieren.
und ja, dito beim Limit (mit etwas anderer Fehlermeldung) - auch hier beim editieren den Apostroph entfernen, dann kann man speichern und der Apostroph kommt dann automatisch wieder:
Mein Vorschlag wäre, im Bearbeiten-Modus die aufwendige Formatierung einfach wegzulassen. D.h. regulär wird meinetwegen 1'234.56 angezeigt oder 1 234,56, aber sobald der Benutzer doppelklickt und das Textfeld erscheint, steht darin nur 1234.56 oder 1234,56. Das ist wahrscheinlich auch fürs Kopieren und Anderswoeinfügen besser.
Das würde nur die halbe Lösung sein, weil du ja weiterhin Locale-spezifische Unterstützung für den Dezimaltrenner brauchst. Da noch die Tausendergruppierung mit zu unterstützen, ist ja kein großer Aufwand. Was hier auf die Nase fällt ist auch nicht der eigentliche Konvertierungsvorgang, sondern eine vorgeschaltete Prüfung mittels Regex, der falsch aufgesetzt ist (für Limits gibt’s einen anderen, bei dem wohl an die Schweiz gedacht wurde, aber mittels Hochkomma auf’s falsche Zeichen geprüft wird).
Ich weiß, ich wollte nur sichergehen, dass da wirklich ein Apostroph und nicht ein Hochkomma steht (wo es herkommt ist da sogar egal) und der Apostroph auch sonst (sprich von dir, solltest du ihn eingeben) das in der Schweiz in dem Kontext verwendete Zeichen ist und nicht das Hochkomma. Wenn man nämlich sowohl Apostroph als auch das eigenlicht nicht gültige Hochkomma unterstützen müsste, wäre das eine mit relativ großem Aufwand verbundene Änderung.
Dann schaue ich auf die richtige Stelle, denn die von dir beobachtete Meldung ist die, die ich erwartet habe.
Dann bau ich uns mal was Schönes … Eigentlich ist der Fix trivial, die in der Source gewählte Umsetzung macht nur das Erstellen sinnvoller Testcases aufwändig.
Um es noch einmal klarzustellen: Ich meine, dass Abschaffen der Formatierung (im Bearbeitungsmodus) ein Fortschritt wäre. Nicht bloß etwas, das halt zur Vereinfachung mit Bedauern hinzunehmen wäre.
Wie gesagt, sind die Tausendertrennzeichen eher unpraktisch, wenn man die Zahl kopieren will. Auch etwa, wenn man einen Betrag schnell verzehnfachen möchte: Aus 1'234 wird 1'2340 … sieht seltsam aus.
Im Indischen wird übrigens so geteilt: 12,34,567.89 – da sind es also keine „Tausendertrennzeichen“.
Selbst, wenn man das machen würde - was mir als durchaus größeren Aufwand erscheint - kann man die Unterstützung von lokalisierten Zahlenwerten nicht einfach über den Haufen werfen, da man dann beim Kopieren und Einfügen derart lokalisierter Werte dann manuell nacharbeiten müsste, um fehlerfreie Eingaben vorzunehmen. Um den Fix kommt man daher nicht herum.
Wird aber erfolgreich geparst; zumindest sagt das mein Testcase, den ich inzwischen um die Geschichte gepackt habe. Nach dem Parsen sollte ja neu angezeigt werden, d.h. der Tausendertrenner “rutscht” dann an die richtige Stelle.
Ich verwende die hier übliche Bezeichnung, wie du selbst sie ja in deiner eigenen Antwort benutzt hast. Ich war zu faul, die deutsche Übersetzung von DecimalFormatSymbols.getGroupingSeparator() zu suchen, die von Non-I18n-Folks intuitiv verstanden wird.
Ist es eventuell möglich (ich habe keine Ahnung von dem Code) das CSV Export : séparateur des milliers eine Folge dieser Änderung ist? Ich vermute, das man dieses Problem ansonsten schon vorher mal gesehen hätte.
Der Code von mir kann es eigentlich nicht sein, da sich der nur im Bereich des Interpretierens von Zahlenwerten bewegte. @AndreasB hat das aber als Basis von anderen Dingen genutzt, so dass ich das nicht zu 100 Prozent ausschließen kann.
Edit: Ich denke, dass das unabhängig davon ist und dass das Problem “schon immer” da war, wenn vorher schon beim CSV-Export Zahlen als Text exportiert wurden und dabei die sprachabhängigen Einstellungen verwendet wurden. Bei einem CSV-Export Zahlen unter Nutzung des Locales als Text zu formatieren, ist IMHO falsch, da sollte die Zahl “as is” rausschreiben. Wobei man das ausprobieren müsste, ob man den Dezimaltrenner an die Spracheinstellung von Excel verwenden muss. Den Tausendertrenner würde ich in jedem Fall aber weglassen bzw. das im Rahmen des Exports konfigurierbar machen.
Das Problem mit dem Export war mit Sicherheit vor ein paar Jahren auch schon ein Problem. Damals hatte ich diverse replaceAll gemacht. Ich habe den Export jedoch seither sehr selten benutzt (und die Zahlenfelder musste man immer bearbeiteten)
Es hängt also sicher nicht mit dieser Behebung zusammen (und wäre schön, wenn es trotzdem gefixt würde, aber ich brauche das sehr selten)
Falls da etwas gemacht würde: es gibt - nach meiner Erinnerung - 2 Hauptprobleme:
Formatierung der Tausender #'###
Währung ist in demselben Feld (also Text und Zahl gemischt). Es wäre “besser”, wenn in einer Row nur der Wert wäre (Zahl) und in einer zweiten Row die Währung (zum Filtern, sortieren, …)
Das mit der Währung müsste man noch genauer anschauen, ich meinte, die Währung stand nur da, wenn es nicht die Hauptwährung war (ich habe CHF eingestellt und das wird - meinte ich mich zu erinnern - NICHT exportiert - nur wenn es $, €, £, … sind wird das mit exportiert)
Super, alles weitere schlage ich aber vor, in dem passenden Thread (den französischen) zu melden bzw. beschreiben, da es ja offensichtlich nicht durch diese Änderung hervorgerufen wird und das damit eher ins Off Topic rutscht.
Eigentlich ist der Fix trivial, die in der Source gewählte Umsetzung macht nur das Erstellen sinnvoller Testcases aufwändig.