fehlerhafter Filterdescriptor?

[newbie-03]

hallo @craig,

'Lernziele' habe ich (eigentlich) nicht , das Sachziel! ist das diese Autofilter Makros laufen über die ich und mikele in anderen threads geschrieben haben, 'datasurfer' und 'filter durchsteppen'.

Dafür braucht es eine konsistente Funktion der Routinen? (dbrange).getfilterdescriptor, (dbrange).filter, (filterdescriptor).getfilterfields und (filterdescriptor).setfilterfields, das ist aber derzeit über 'Speichern - neu Laden' nicht gegeben.

Ich möchte mit den Makros gerne etwas zum besseren - leichteren handling von calc auch für andere Leute beitragen, da ist es zu umständlich wenn man immer dazu erklären muß 'LO calc hat da einen Fehler, deshalb mußt du beim Laden immer darauf achten ob ein Autofilter gesetzt ist, und den ggf. durchgucken und von Hand neu setzen ... '

Vor lauter 'Verzweiflung' weil ich keinen Ansatz finde den Punkt endgültig zu analysieren oder korrigiert zu bekommen habe ich mir halt fast eine Entwicklungsumgebung zusammengestoppelt, und würde - wenn es denn sein muß - auch versuchen den Punkt selbst zu finden ... dementsprechend die Frage nach tutoring.

Ansonsten versuche ich gerade einen workaround zu konstruieren, ein Makro welches automatisch nach dem Laden alle gesetzten Autofilter speichert, Autofilterung für die Bereiche aus und wieder einschaltet, und die Filtrierung dann mit korrigierten Werten für .field neu setzt. Das ist aber auch nicht trivial, und ist - wenn ich mit dem bug recht habe - keine 'schöne' Lösung, weil eine Lösung die auch für andere Anwender / Anwendungsfälle korrekte Ergebnisse liefert natürlich viel schöner wäre ...

Daß ich dabei nebenbei etwas lerne ist ein 'windfall profit'.

b.G.



b.

[craig]

Hallo b.

OK.

Da kann ich Dir nicht weiter behilflich sein und klinke mich an dieser Stelle aus.

Bis dann...

[mikele]

Hallo,
soweit ich es nachvollziehen konnte, tritt das Problem seit LO6.2 nicht mehr auf.

[newbie-03]

moin,

@craig: danke soweit,

@mikele:

> soweit ich es nachvollziehen konnte, tritt das Problem seit LO6.2 nicht mehr auf.

danke, das hattest du schon im November geschrieben, ich hatte es auch gelesen, aber bei mir sind seit Version 4.1.6.2 bis zur 7.0.0.0.a0+ von vor zwei Wochen alle Versionen 'buggy', sowohl unter Windows als auch unter Linux (Debian / Kali). Die 6.2.8.2 ist meine meistgenutzte Version weil sie ein paar slowdowns wegen Kommentaren nicht ganz so schlimm hat wie andere Versionen.

Testfall: deine hochgeladene Datei, aufrufen, button klicken, Anzeige '2', richtig wäre '0', (ich denke Spaltenoffset addiert, Zeilenoffset nicht abgezogen da sich ein negativer Wert ergeben würde).

mit AOO hingegen funktioniert es richtig, Anzeige '0', getestet mit ver. 4.1.7 portable.

Wenn es bei dir mit 6.2.8.2 richtig läuft ist natürlich nicht auszuschließen daß es an irgendwelchen Konfigurationen / Einstellungen liegt die mal so und mal anders sein können ... wie könnte man das herausbekommen.

Ich wäre ja erstmal zufrieden wenn es bei mir auch richtig funktioniert, dann kann die Analyse warum es falsch lief meinetwegen hintenanstehen ...

reg.

b.

[mikele]

Hallo,
die 2 ist insofern richtig, dass ja nach Spalte C gefiltert wird, welche ja die Spalte mit Index 2 ist. Entscheidend ist, ob die Eigenschaft Field den absoluten Wert angibt oder den relativen (relativ zum Datenbereich).
Scheinbar/offensichtlich gab es da Änderungen in der Entwicklung ...

[newbie-03]

hallo @Mikele,

'Änderung in der Entwicklung' - kann ich mir eigentlich nicht vorstellen, würde völlig unnötig einen Bruch in der Kompatibilität verschiedener Versionen bewirken, und zu AOO, und zum TDF Standard ... ich denke so verrückt ist keiner. Dazu paßt auch nicht daß nach einem 'refresh' der Filtrierung eines Bereichs wieder 'relative' Werte für .field genommen werden.

Fakt ist - für mich - alle Versionen von 4.1.6.2 bis 7.0.0.0.a0+ speichern falsche Werte für .field in den Dateien ( - äh wenn die Datenbankbereiche einen offset zu A1 haben und oberhalb der '45 Grad Diagonalen' liegen - ) nach Neuladen funktioniert zwar das Filtern von Hand / Maus (Kopfzeile anklicken), aber Manipulationen am Filter per Makro produzieren Fehler.

Ich habe mal versucht ein 'Korrekturmakro' zu erstellen,

mikele_test_filterdescriptor_test12.ods

(13.69 KiB) 310-mal heruntergeladen

,
das ist dermaßen 'dreckig' aus Fundstücken im web zusammengestoppelt und 'erärgert' daß es fast schon künstlerisch wertvoll ist, siehe anliegende Datei, ich würde mich freuen wenn:

- mal ein paar Leute ausprobieren ob der Fehler auf ihrem System auch auftritt, und wenn nicht dann hier schreiben mit welcher Version sie arbeiten,

- mal ein paar Leute ausprobieren ob das Korrekturmakro bei ihnen funktioniert,

- und jemand der sich mit Makroprogrammierung auskennt das vielleicht etwas 'glatter' umschreibt,

ich würde dann versuchen es beim Laden betroffener Dateien automatisch laufen zu lassen und mich über die Nicklichkeiten nicht mehr ärgern.

vielen dank für alle Hilfe,

b.

[newbie-03]

--- Hilfe zum Gegencheck erbeten, ist ganz einfach ---

ja ... das mit der Korrekturrechnung wäre zu schön gewesen, funzt aber leider nicht ...

es tritt ein merkwürdiger Effekt auf:

bei der Filtrierung eines Datenbankbereichs dessen header teils links / unter- und teils rechts / oberhalb der '45-Grad-Diagonalen' A1-B2-C3-D4-E5... liegt und in der eine Spalte mit 'Kopf' links und eine mit Kopf rechts der Diagonalen gefiltert sind, wird in der gespeicherten Datei

mikele_test_filterdescriptor_test13c.ods

(13.33 KiB) 332-mal heruntergeladen

folgendes für die Definition der Filtrierung gespeichert: siehe Bild

132120_mikele_test_filterdescriptor_test13c_file.jpg (285.66 KiB) 5641 mal betrachtet

, die beiden weit eingerückten Zeilen und dort 'field-number="-2"' und 'field-number="1" ... wenn man das etwas komplexer verrechnet kann man sich '0' und '3' für die Filterspalten relativ zum Datenbankbereich erarbeiten. Das muß auch calc so machen, es zeigt die beiden Spalten B und E als gefiltert an, und auf dem Bildschirm / mit der Maus kann man mit den Werten und Filtrierungen weiterarbeiten.

Aber! wenn man per Makro mit den Methoden 'getfilterdescriptor' und 'getfilterfields' auf die Filtrierung zugreift werden andere Werte für .field genommen, und z.B. für die Beispieltabelle zwei! Filterfield Einträge mit '1' für .field angezeigt, siehe anliegenden screenshot

132120_mikele_test_filterdescriptor_test13c_macroedit.jpg (175.4 KiB) 5641 mal betrachtet

. Ich sehe - bisher - keine Möglichkeit die auseinanderzuhalten und zu entscheiden für welchen der Wert von .field wie korrigiert werden muß. Im Beispiel geht das über den Wert in der Zelle, 'name2' ist Spalte B oder '0' und 'vorname2' Spalte E oder 3 relativ zum Datenbankbereich, aber das taugt nicht für automatisch oder für größere Projekte.

(mMn weil irgendwo ein bug a la Verwechselung von Zeilen- und Spaltenoffset passiert ist)

Es gibt jetzt zwei Möglichkeiten, entweder habe ich mich auf meinem System total verkonfiguriert und verlaufen, und das macht Mist den andere Rechner nicht machen (ist aber unwahrscheinlich weil es auf zwei ähnlichen Rechnern unter verschiedenen Systemen (Win/lin) und mit verschiedenen Versionen von LO gleichartig auftritt), oder ich bin nahe am Kern eines Problems was möglicherweise auch Ursache vieler anderer verwirrender bugs mit Filtern ist (ich sah bei meinen Recherchen ob 'mein Fehler' schon irgendwo beschrieben ist einige).

Ab dem Moment wo zwei verschiedene Filterspalten auf den gleichen Wert für .field umgerechnet werden ist leider eine Korrekturrechnung 'mit Bordmitteln' (Makros) nicht mehr möglich.

Die Filterfields habe ich unter 'thiscomponent' oder 'oDoc' bisher nicht gefunden, obwohl sie ja eigentlich drinstehen müßten? aber es gibt da zuviele classes, superclasses, types, methods ... ich fand sie erst unter 'orange' nach 'oDBRanges.getByIndex', und da bereits 'falsch', noch vor 'getfilterdescriptor' und 'getfilterfields',

Hilfe kann ich jetzt gebrauchen:

- daß andere Leute das Verhalten auf anderen Rechnern gegenchecken, nicht daß ich für ein Exotenproblem die Pferde scheu mache,

- wenn jemand weiß wo die Filterfields in 'ThisComponent' versteckt sind daß man da mal nachgucken könnte,

- wenn jemand weiß, oder jemanden kennt der weiß, auf welchem Weg die Werte für die Speicherung der Datei berechnet werden, und auf welchem sie beim Laden zurückgerechnet werden, dann könnte man da mal im code gucken, ohne solchen Hinweis stehe ich mit den verschiedenen Ebenen der Benennung auf dem Schlauch ...

'getfilterdescriptor' versteckt sich in 'databaseranges' unter:

elementtype::methods::method(6)

in oDoc oder 'ThisComponent' entsprechend unter:

databaseranges::elementtype::methods::method(6)

vielen Dank für alle Hilfe, ich hoffe es kann beitragen LO weiter zu verbessern,

b.

(P.S. ich stelle die Frage auch ins englische 'ask')

[mikele]

Hallo,
ich muss meinen Kommentar zurückziehen. Der Fehlerdesriptor zeigt auch unter LO 6.2 dieses seltsame und nicht nachvollziehbare Verhalten.

[newbie-03]

hallo @Mikele,

danke für's recheck, ich zweifelte schon an meinem Verstand oder der Genauigkeit meiner Arbeit,

'Fehlerdesriptor' ist ein schöner freud'scher Vertipper

jetzt brauchts nur noch jemanden der die Stelle im code findet ...

[newbie-03]

hallo @Mikele,

ich schulde dir viel Dank für viel Hilfe, DANKE!

ich habe versucht das problem weiter aufzudröseln und bin darauf gestossen daß calc im *.ods format (wohl) falsche werte speichert welche spalten gefiltert werden sollen.

im *.xlsm format passiert das nicht ???

ich habe dort: https://bugs.documentfoundation.org/sho ... ?id=132488 einen bug dazu 'gefiled', vielleicht kannst du einmal nachgucken ob ich das soweit richtig verstanden, getestet und beschrieben habe.

der bug ist - wenn richtig - wohl ziemlich grundlegend, deshalb wäre mir lieb wenn möglichst bald jemand gegencheckt daß ich nicht einem hoax aufgesessen bin.

natürlich ist auch jeder andere willkommen und eingeladen zum test und evtl. fixing beizutragen.

b.g. bleibt gesund!

b.