LibreOffice-Forum

Hallo,
das Thema viewtopic.php?f=12&t=25341 hat mich auf ein verwirrendes Verhalten des Filterdescriptor gebracht:
Wendet man auf einen Bereich einen Autofilter (oder auch einen anderen) an, dann werden die Filterkriterien in den FilterFields abgelegt. Die Spalte nach der gefiltert wird, wird in der Eigenschaft Field abgelegt. Diese ist relativ zum Datenbereich.
In meiner Beispieldatei ist der Datenbereich "bereich1" der Bereich C6:D15. Filtert man nun nach Spalte C, dann hat Field den Wert 0. Speichert man die Datei ab, schließt und öffnet sie wieder, dann liefert Field nun den Wert 2! Erst wenn der Filter entfernt und neu gesetzt wird, sind wir wieder bei 0 ...
Aktuell habe ich das Verhalten nur unter LO 5.4.6 testen können.
Kann jemand das Verhalten bestätigen? Ist es ein Bug?
Zu Testzwecken habe ich mal ein Button eingefügt, der den Field-Wert anzeigt.

Ergänzung: Unter LO 6.2.8.2 tritt das Problem nicht auf.

Hallo mikele,

mikele hat geschrieben: In meiner Beispieldatei ist der Datenbereich "bereich1" der Bereich C6:D15. Filtert man nun nach Spalte C, dann hat Field den Wert 0. Speichert man die Datei ab, schließt und öffnet sie wieder, dann liefert Field nun den Wert 2! Erst wenn der Filter entfernt und neu gesetzt wird, sind wir wieder bei 0 ...

Dies kann ich nicht bestätigen.
Gestestet mit:

1. Version/Release: 6.2.2.2 portable de
2. Version/Release: 6.2.5.2 (x86) portable de
3. Version/Release: 6.3.2.2 (x64) de
4. Version/Release: 6.4.0.0.alpha0+ (x64) en/ us

Mit nicht bestätigen meine ich:

1. heruntergeladene Datei öffnen → Makro starten → Meldung: „2“
2. Alle Filterungen aufheben → Makro starten → Meldung: „Kein Filter“
3. Speichern → LibO beenden
4. Datei erneut öffnen → Makro starten → Meldung: „Kein Filter“
5. Einen Filter setzen → Makro starten → Meldung: „2“
6. Speichern → LibO beenden
7. Datei erneut öffnen → Makro starten → Meldung: „2“

Fazit: Es wird in jedem Fall erkannt, ob ein Filter gesetzt wurde oder eben nicht.

Hallo,
danke für die umfangreiche Testung.
Mein Problem ist weniger, ob der Filter gesetzt ist oder nicht, sondern ob die richtige Filterspalte erfasst wird. Im Filterdescriptor sollte die Spalte relativ zum Datenbereich in der Eigenschaft Field erfasst werden (Spalte C entspricht 0).
Unter LO Version 5 scheint der Filterdescriptor allerdings manchmal den absoluten Wert (Spalte C entspricht 2) zu liefern.

Hallo mikele,

mikele hat geschrieben:Unter LO Version 5 scheint der Filterdescriptor allerdings manchmal den absoluten Wert (Spalte C entspricht 2) zu liefern.

Dies kann ich bestätigen, wobei bei mir immer
Fieldindex = Spaltenindex ist Habe Deine Datei auch unter AOO4.1.6 geöffnet, da sehen die Ergebnisse von MRI anders aus. Nicht nur das der Fieldindex einen anderen Wert darstellt, sondern auch
die Filterconnections zu Field(0) in LibO = AND und in AOO = OR.

Ich nehme mal an, dass auch hier die API von LibO geändert wurde und dies nun zu unterschiedlichen Ergebnissen führt.

Dies zeigt mal wieder die sich öffnende Schere zwischen LibO und AOO.
Man wird wohl in Zukunft in seinen Makros wie folgt abfragen müssen:

1. Hallo Office: Bist Du AOO oder LibO
2. Wenn LibO, welche Version/ welches Release bist Du?

Nach der Abfrage, das zur Rückmeldung passenden Makro starten.

mikele hat geschrieben:schließt und öffnet sie wieder, dann liefert Field nun den Wert 2! Erst wenn der Filter entfernt und neu gesetzt wird, sind wir wieder bei 0 ...
Aktuell habe ich das Verhalten nur unter LO 5.4.6 testen können.

Ich vermute mal, dass kurz vor "LO 5.4.6" die Änderung des Filterdescriptor an der API erfolgte.
Konnte dazu noch keinen HInweis in der Dokumentation/ den Versionshinweisen finden.
Bei der Suche nach einem entsprechenden Bug-Report habe ich auch noch nichts vergleichbares gefunden.

also bei mir seit Version 4.1.6.2 (frühere nicht getestet):

Datei laden mit gesetztem Filter: getFilterDescriptor setzt den Wert für Field relativ zum linken Blattrand,
mit der Besonderheit:

- beginnt der Bereich in dem der autofilter arbeitet nicht in der ersten Zeile wird der vertikale 'offset' des Bereichs (also der Wert für Zeile gezählt ab 0) von dem Wert für field abgezogen,

- es sei denn! der vertikale offset ist größer als der horizontale offset (relativ zu A1), dann unterbleibt der Abzug,

Nach autofilter aus - ein wird der Wert für field immer relativ zum gefilterten Bereich gesetzt.

(vermuteter Fehler im code: für field soll der Wert von 'Spalte' abzüglich 'linke Spalte des Bereichs' gesetzt werden, stattdessen wird 'Spalte' abzüglich 'obere Zeile des Bereichs' genommen)

mit so etwas kann man nicht verläßlich programmieren ...

shit - einmal kurz Bild von craig angeguckt und schöner ausführlich geschriebener Beitrag weg

Neuversuch in Kurzform:

- es werden tw. falsche Werte für 'Filterfield' in den Dateien gespeichert, man kann die *.ods Datei mit einem zip-Programm öffnen (z.B. 7-zip), darin findet man eine content.xml, und in der steht unten die Definition des Daten(bank)bereichs und des Filters,

- der Zeilenoffset hat Auswirkungen auf den Wert für Filterfield, kann man gucken indem man den Datenbereich verschiebt, die Datei speichert und neu lädt, cave: negative Werte werden 'vermieden', entweder unterbleibt der Abzug des Zailenoffsets, oder ein negatives Ergebnis wird durch 0 ersetzt?

- wenn man im Beispiel von Mikele den Datenbereich nach C4:D13 verschiebt und Spalte C filtert erhält man als Wert für Filterfield '2' (Spalte absolut), wenn man Spalte C freigibt und D filtert ergibt sich '0' (Spalte relativ),

- vermutete beabsichtigte Kalkulation: gefilterte Spalte (absolut) minus 'Spaltenoffset des Datenbereichs' um einen Wert relativ zum Datenbereich zu erhalten, vermutete fehlerhafte Kalkulation: statt Spaltenoffset den Zeilenoffset abgezogen,

- LO - calc - BASIC macht auch Fehler wenn man eine Datei speichert und neu lädt in der Autofilter aktiv aber für keine Spalte ein Filter gesetzt ist, nach Neuladen einen Filter setzt und dann Filterfield anguckt,

- einen Filter per Makro zu setzen geht entsprechend auch schief wenn Autofilter beim Laden der Datei schon aktiv war,

- vermutet warum das bisher keinen gestört hat: es arbeiten mehr Leute mit Mäuseklickerei als mit Makros, wenn der Datenbereich bei A1 anfängt oder sein Startpunkt irgendwo auf der Diagonalen A1-B2-C3-D4 ... liegt fällt der Fehler nicht auf, wenn er mal jemandem auffällt ist alles verzwickt genug dem nur schwer nahezukommen, und nach einiger Zeit sagt man (sich) 'ist halt buggy, mach ich workaround oder mach ich was anderes ... '

- für mehr bräuchte ich einen Debugger, Kenntnisse über die Variablen, über die code- und Datenstruktur, hab ich nicht, ist komplex, liest hier jemand mit der das Problem angehen kann? Wäre schön weil es eine Basisfunktionalität ist,

- @craig: versuche mal:

heruntergeladene Datei öffnen
(damit der button funktioniert mußte ich noch noch
<menu - view - toolbars - form controls - deactivate design mode>
einschieben)
→ Makro starten → Meldung: „2“
Autofilter komplett ausschalten <data - autofilter>
Autofilter wieder einschalten <data - autofilter>
Spalte C wieder filtern
→ Makro starten → Meldung: „0“

das ist das Problem, '2' war falsch, '0' ist richtig,

Datei speichern und schließen,
Datei neu laden,
→ Makro starten → Meldung: „2“

neu geladen -> wieder falsche Berechnung

ich vermute weniger eine geänderte API, sondern daß sich - schon vor vielen Jahren - ein Programmierer 'verdaddelt' hat, ich fand den Fehler in allen Versionen seit 4.1.6.2, frühere habe ich noch nicht getestet.

MRI sieht 'nett' aus, aber bei mir scheiterten bisher alle Installationsversuche ...

beste Grüße,



b.

Hallo b,

b hat geschrieben:ich vermute weniger eine geänderte API, sondern daß sich - schon vor vielen Jahren - ein Programmierer 'verdaddelt' hat, ich fand den Fehler in allen Versionen seit 4.1.6.2, frühere habe ich noch nicht getestet.

Ich bin zwar kein Experte was den Quellcode von LibreOfiice/ OpenOffice angeht,
aber ich versuche mal Deine Aussage wie folgt zu kommentieren.

Was ist die API (die API, weil die Schnittstelle)?
Die API = application programming interface, wörtlich ‚Anwendungs­programmier­schnittstelle
Sie ist aber nicht nur Schnittstelle, sondern dient auch der Dokumentation der Schnittstellen, etc.
Von den Dokumentationsseiten gelangt man auch zum jeweiligen Quellcode, welcher hinter einer "Anweisung", "Eigenschaft", "Methode", etc. führt.
Dieses sind IDL-Dateien, welche in C++ geschrieben wurden.
Genau hier liegt Knackpunkt. Der Punkt wo irgendwann eine Änderung stattgefunden hat oder sich irgendwann ein Fehler eingeschlichen hat. In jedem Fall hat dies ein Programmierer vollbracht und zwar im Quellcode.


Folglich:
Wird der Quellcode geändert, dann ändert sich auch die API.
Ich habe keine Ahnung davon wie die Zusammenhänge in Sachen API-Verwaltung sind.
Wie, mit welchem Code, etc. wird dieses Monster gesteuert
Ich habe auch kein Interesse mich näher in diese Thematik einzuarbeiten.

Wenn Du Lust und Laune hast, kannst dieses als BUG melden.

Einfach dort anmelden und eine genaue Beschreibung abliefern.

Die API wurde geändert, wenn ja, dann muss zuvor der Quellcode vom Programmierer geändert werden.
siehe hier die API zu Dokumenteigenschaften:
XDocumentProperties Interface Reference
siehe hier der Quellcode zur API:
https://api.libreoffice.org/docs/idl/re ... ource.html

hallo @craig,

danke für die Erläuterungen,

ich versuche mich mal in die Zusammenhänge API - Quellcode einzulesen, für einen newbie nicht ganz einfach, und z.B. in so etwas - https://api.libreoffice.org/docs/idl/re ... ource.html - steht nicht viel Erhellends drin

MRI habe ich jetzt zum Laufen bekommen, aber es gelingt mir noch nicht die Routinen zu identifizieren die z.B. beim Laden und Speichern die Werte liefern, wenn hier jemand mitliest der das kann ... ich denke der bug ist ausreichend eingegrenzt daß man ihn leicht erlegen kann ... wenn man die Kenntnisse hat ...

wenn jemand keine Lust / Zeit hat das selbst zu machen, aber mir erklären kann wie der Weg der Datenstruktur in die Datei ist, und wie wieder zurück, also wie die Daten unterwegs heißen und über welche Module das läuft, dann gucke ich gerne selber weiter, ich lerne ja dabei ... aber jetzt hunderte Seiten Dokumentation zu wälzen wo evtl. mehrere Zwischenschichten mit unterschiedlichen Bezeichnern reingrätschen - ich fand die Begriffe die im Makro vorkommen nicht im Quelltext - dazu fehlt mir die Zeit ... und Frustrationstoleranz ...

als bug gemeldet habe ich das Problem schon, aber unter dem Gedanken daß die Routine(en) getfilterfield / setfilterfield irgendwie Quatsch machen, unterdessen denke ich halt daß die Interpretation der Daten zum Speichern und der zu ladenden Datei für die Datenstruktur irgendwie buggy sind ...

MRI war nicht ganz einfach, die meisten Links verwiesen auf eine Version 1.1.2 osä, bei der war kein Link zu neueren Versionen vermerkt, erst nachdem ich mit hartnäckigem Suchen eine 1.3.3 und dann 1.3.4 aufgetrieben habe wurde es besser.

Also die Werkzeuge habe ich jetzt eigentlich (Quellcode, Compiler, Debugger (gdb) und MRI), build mit --dbgutil funktioniert, aber mir fehlen Kenntnisse zu den Datenstrukturen und Erfahrung im Umgang mit dem Werkzeug ...

b.G.



b.

Hallo b.,

es tut mir leid, ich werde aus Deinen Angaben nicht so ganz schlau

Was ist Dein Lernziel?

1. Möchtest Du ein Office-Paket programmieren?
   ODER
2. Möchtest Du Makros unter Calc, Writer, etc. schreiben?