Feldtyp „Betrag (einfach)“ zum Editieren etwas umständlich (1'000er-Apostroph)

Hallo

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)

image

Gruss
Thomas

Hi Thomas,

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 :slight_smile:

2 Likes

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.

Hallo @kimmerin

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:

image

Gruss
Thomas

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 … :wink: 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.

Bau beendet. Muss nur noch vom Meister akzeptiert werden :wink:

1 Like