Fehler beim Laden / Einlesen / Speichern von Filtern, filterfields unbrauchbar, Dateien nicht ODF Standard konform

[newbie-03]

moin,

das Problem aus https://www.libreoffice-forum.de/viewto ... 362#p69023, warum calc nach dem speichern und neu laden von Dateien mit gesetzten Filtern Fehler macht, ist weitgehend eingegrenzt, siehe dort (auf englisch): https://bugs.documentfoundation.org/sho ... ?id=133336.

Das Problem ist etwas exotisch, es betrifft nur Speicherung im .ods Format (und den Ablegern davon)(aber das ist der Standard für calc), tritt nur auf wenn beim Speichern ein Filter gesetzt ist, und nur wenn dessen 'Datenbankbereich' abseits einer Diagonalen A1-B2-C3-D4-E5-F6... beginnt, und nur beim neu laden zuvor gespeicherter Dateien. Bei einer neu erstellten Datei und beim ersten Speichern ist alles ok, nach neu Laden sind die 'filterfield' Werte unbrauchbar.

Es betrifft aber alle! Filter, sowohl Auto- als auch Standard- und Advanced-Filter, kommt also durchaus mal vor.

Daneben sind ab der zweiten Speicherung die Dateien nicht mehr ODF 1.2 (extended) konform, negative Werte für Filterfelder sind dort nicht vorgesehen.

m.E. sind für das 'UI' (die grafische Oberfläche wo man die dropdown buttons anklickt) die Fehler der Filterfelder durch einen 'Gegenfehler' 'table-orientation="column"' überspielt (oder zum Ausgleich von diesem Fehler eingeführt?).

Was mich sehr wundert ist der 'verhaltene'? Elan der dortigen community das Thema aufzunehmen und den bug zu fixen.

Mir scheint Version 7.0 eine einmalige Gelegenheit ein paar Kompatibilitätsprobleme zu vermeiden die sich vielleicht beim fixing ergeben, was macht man mit alten Dateien wenn man die Interpretation beim Einlesen korrigiert? wie hält man alte und neue Dateien auseinander? LO 7.0 soll den neuen Standard ODF 1.3 verwenden, das wäre eine Chance jedenfalls für Dateien im neuen Standard von Anfang an richtig zu arbeiten, dafür müßte man sich aber beeilen.

Drei Bitten:

- Wenn hier jemand mitliest der mein radegebrochenes englisch verstehen kann und am sauberen Funktionieren von calc interessiert ist wäre es nett wenn er den bug einmal nachcheckt, ich bin mir zwar weitgehend sicher, aber besser ist besser.

- Wenn dieser jemand (oder ein anderer) dort (bei bugzilla) die Behandlung des Themas etwas 'anschieben' kann wäre das toll, ich verzweifele allmählich als einsamer Rufer in der Wüste.

- Wenn jemand mir Tipps geben kann wie die Konstruktionen in der Datei und im im Speicher sein sollen, und in welchen Modulen - mit welchen Routinen - das Einlesen und Speichern gemacht wird, also jemand der C++ programmieren kann und schon mal LO debuggt hat?, würde ich mich auch sehr freuen und selber versuchen weiter schlau zu werden und den Knackpunkt zu finden. Im Moment stehe ich da sehr am Anfang und scheitere daran das der Weg von einer Programmzeile zur Ausführung halbwegs nachvollziehbar ist, der Weg eine fehlerhafte Ausführung zu identifizieren von der man nur weiß das sie fehlerhaft ist, aber nicht wo sie stattfindet, und dann das entsprechende Modul und dort die Programmzeile zu finden aber sehr schwer ist. Ebenso ist es schwer zu analysieren wie der Verarbeitungsweg im code richtig wäre wenn man nur weiß daß er falsche Ergebnsse bringt, aber nicht ob das z.B. an Fehlern beim einlesen des Filterfields oder von dessen Datenbankbereich liegt, oder ob richtig eingelesen aber falsch verarbeitet wird ...

Und wenn man dann etwas ändern könnte muß man natürlich furchtbar aufpassen daß man nicht anderswo Fehler injiziert, also da braucht es mehr Erfahrung als ich habe ...

Kurzfassung: ich denke ich habe das Problem klar identifiziert, brauche aber Hilfe bei der Lösung ...

danke vorab für alle Hilfe, und bleibt gesund ...

beste Grüße,



b.

[newbie-03]

hurraaaa ... naja vielleicht ... vielleicht habe ich's gelöst,

siehe bug 133336 aus dem vorigen Beitrag, ich freue mich wenn möglichst viele Leute das mal gegenchecken,

(erfordert entweder selbst kompilieren, oder warten bis der patch in die daily builds kommt)