LibreOffice-Forum

moin,

Autofilter 'spinnt' bei bestimmten Datumsfeldern, bei bestimmten formatierten Zahlenfeldern, erst recht beim Setzen via Makro, und ein paar Rechenfunktionen sind auch eigenartig ... - JJ-MM-TT wird falsch gefiltert, 'führende Nullen' werden falsch gefiltert, '1' in ein fragwürdiges Datum umgerechnet,

Ich habe diese Hauptfrage für die 'Überflieger' und gegen Ärger über lange Vorreden mal obenan gestellt, Details kommen gleich.

Für die Leute die sich für meine Herangehensweise interessieren habe ich unten unter 'Geschichte' ein paar Sachen notiert, die üblichen 'Foren-Blockwarte' bitte ich erst dort nachzulesen bevor sie den thread vollspammen.

Für die effektiven unter den usern und Helfern möchte ich schnell zu den Hauptfragen kommen, entschuldigt daß ich mehrere Fragen in einem thread stelle, meine Herangehensweise ist eher 'projektorientiert' und die Fragen sind miteinander verwandt.

in diesem thread viewtopic.php?f=6&t=15148&start=10 geht es um ein ausgesprochen praktisches Makro, die dortige Frage ist gelöst, es gibt aber ein paar Unzulänglichkeiten. Die angehängte Tabelle enthält Beispiele.

Kurzfassung (für diejenigen die 'einsteigen' wollen ist unter 'Langfassung' eine ausführliochere Darstellung):

- JJ-MM-TT wird falsch gefiltert?,
wenn man den Autofilter im Datenbereich einschaltet und in der JJ-MM-TT formatierten Spalte eine Auswahl trifft werden alle! Zeilen ausgeblendet. Das m.E ein Fehler.

- 'führende Nullen' werden falsch gefiltert,
wenn man den Autofilter im Datenbereich einschaltet und in der Spalte M - wo die Zahlen als 'mit zwei führenden Nullen' formatiert sind (wieso eigentlich '2'?) - eine Auswahl im dropdown Feld trifft funktioniert das, aber wenn man die Auswahl über das Makro 'Filtershortcut' aktiviert funktioniert es nicht, es werden alle! Zeilen ausgeblendet. Das m.E ein Fehler.

- '1' wird in ein fragwürdiges Datum umgerechnet,
nebenbei ist mir in der Spalte 'K' aufgefallen daß Calc die Zahl '1' in ein anderes Datum umrechnet als Excel, bei Calc ist es der 31.12.1899, bei Excel der 01.01.1900, Vorsicht - Vorsicht - Vorsicht beim Übernehmen von Tabellen aus der jeweils anderen Welt!

- die Zählung und Behandlung von 'führenden Nullen' ist merkwürdig,
wo ich in Excel mal mit '1' führenden Null eine Anzeige wie '01' erreicht habe mußte ich in LO '2' führende Nullen anfordern, das sind eher keine 'führenden Nullen' oder 'trumps' ('leading zeros'), sondern 'angezeigte Ziffern' oder 'digits to display', in Excel 2010 ist das Auswahlfeld für die trumps weggelassen? Über den 'Format Code' funktioniert alles.

Langfassung:

- JJ-MM-TT wird falsch gefiltert?,
wenn man den Autofilter im Datenbereich einschaltet und in der JJ-MM-TT formatierten Spalte eine Auswahl trifft werden alle! Zeilen ausgeblendet. Das m.E ein Fehler.
Recherchstand: bei anderer Formatierung soll es gehen (z.B. JJJJ-MM-TT, stimmt), bei mehreren anderen aber auch nicht (siehe Beispieltabelle), bei LO Versionen vor 5.2 soll es gehen (habe ich noch nicht probiert).
Meine Menung: ich erwarte von moderner Software und 'der Tabellenkalkulation die ich schon immer haben wollte' daß sie mit allen Formatierungen die sie 'anbietet' auch umgehen kann.
Problembewußtsein: natürlich ist JJ-MM-TT ein für user gefährliches weil 'verwechslungsgefährdetes' Format, aber wenn es 'erlaubt' ist, und wo es gegen zu breite Tabellen manchmal sinnvoll ist, sollte ein Programm 'richtig' damit umgehen.
Meine Vermutung: das hängt an der - verzeiht den Ausdruck - bescheuerten 'click-o-mania' die irgendein praxisferner '*****' für die Filterung von Datumsfeldern eingebaut hat, vielleicht wollte er 'Fortschritte' von M$ und Excel nachäffen? Ansonsten sollte der Umgang mit Datumsdaten 'straightforward' sein können, (ein Datum ist! eine Zahl, was eingetippt oder angezeigt wird wird anhand der Formatierung der Zelle in eine Zahl umgerechnet, diese Zahlen werden behandelt, und das Ergebnis wird anhand der Zellformatierung wieder für die Anzeige aufbereitet). Das wäre stabil, und würde selbst für gemixte JJ-MM-TT, TT-MM-JJ, MM-TT-JJ Formatierungen in einer Spalte funktionieren, unabhängig davon ob das 'sinnvoll' ist, der Unsinn läge am und wäre Schuld des users.
alternativer Lösungsvorschlag: wenn man einfach genau das für die Auswahlliste und für die Filterung nutzt was angezeigt wird müßte es auch gehen, und würde selbst für gemixte JJ-MM-TT, TT-MM-JJ, MM-TT-JJ Formatierungen in einer Spalte funktionieren, unabhängig davon ob das 'sinnvoll' ist, der Unsinn läge am und wäre Schuld des users.
noch eine Bitte: wenn man die o.g. click-o-mania irgendwie abschalten kann wäre ich für einen Hinweis dankbar, wenn nicht sollte man überlegen das in zukünftige Versionen als Option einzubauen.

- 'führende Nullen' werden falsch gefiltert,
wenn man den Autofilter im Datenbereich einschaltet und in der Spalte M - wo die Zahlen als 'mit zwei führenden Nullen' formatiert sind (wieso eigentlich '2'?) - eine Auswahl im dropdown Feld trifft funktioniert das, aber wenn man die Auswahl über das Makro 'Filtershortcut' aktiviert funktioniert es nicht, es werden alle! Zeilen ausgeblendet. Das m.E ein Fehler.
Recherchstand: keine passenden Beiträge dazu im web gefunden.
Meine Menung: es wird wahrscheinlich 'am Makro liegen', anhand des - etwas umständlichen - Konzepts wie in LO ein Autofilter angesprochen wird müßte das Makro die Formatierung der Zelle analysieren und beim Setzen der Filterfelder berücksichtigen? Also Excel kann das alles 'intuitiv'. Ob sich da jemand die Mühe gemacht hat jegliches bescheuerte Format zu analysieren was user vielleicht mal anlegen, oder KI dahintersteckt? oder ein schlichtes Konzept wie 'schreibe einfach das in ein Filterkriterium was der user anbietet *ohne!* es vorher in einer Variablenübergabe zu vermurksen' mehr leistet ... ist beyond my scope.
Problembewußtsein: natürlich sind führende Nullen Quatsch, ich meine sie waren irgendwo (Excel) mal für eine funktionierende Sortierung von Kalenderwochen nötig, und ich benutze sie wenn ich Dateinamen konstruiere die die Kalenderwoche enthalten und vernünftig sortiert im Ordner angezeigt werden sollen. Und wenn so etwas vom Programm angeboten wird sollte das Programm auch damit umgehen können.
Meine Vermutung: siehe 'meine Meinung', mit enem vernünftigen Konzept müßte so etwas straightforward funktionieren, (eine Zahl ist! eine Zahl, was eingetippt oder angezeigt wird wird anhand der Formatierung der Zelle in eine Zahl umgerechnet, diese Zahlen werden behandelt, und das Ergebnis wird anhand der Zellformatierung wieder für die Anzeige aufbereitet). Das wäre stabil, und würde selbst für gemixte ein - zwei - drei führende Nullen Zellen in einer Spalte funktionieren, unabhängig davon ob das 'sinnvoll' ist, der Unsinn läge am und wäre Schuld des users.
alternativer Lösungsvorschlag: wenn man einfach genau das für die Auswahlliste und für die Filterung nutzt was angezeigt wird müßte es auch gehen, und würde selbst für gemixte ein - zwei - drei führende Nullen Zellen in einer Spalte funktionieren, unabhängig davon ob das 'sinnvoll' ist, der Unsinn läge am und wäre Schuld des users.

- '1' wird in ein fragwürdiges Datum umgerechnet,
nebenbei ist mir in der Spalte 'K' aufgefallen daß Calc die Zahl '1' in ein anderes Datum umrechnet als Excel, bei Calc ist es der 31.12.1899, bei Excel der 01.01.1900, Vorsicht - Vorsicht - Vorsicht beim Übernehmen von Tabellen aus der jeweils anderen Welt!
Recherchstand: noch nicht gesucht, ich hatte aber neulich mal irgendwo ähnliche Irritationen um die Jahr -1, 0, 1 herum (es gibt kein Jahr '0'?) was alles genaue Rechnen mit alten Zeiten etwas unscharf oder sehr aufwendig macht.
Meine Menung: schon die Definition des 01.01.1900 als '1' ist fragwürdig bzw. schwierig zum Rechnen mit Zeiten als Bruchteile von Zahlen, der 01.01.1900 zwölf Uhr mittags wäre ja dann 1,5? es ist aber seit dem Ursprung dieser Definition zur Zeitdarstelleung um 0:00 h erst eine Spanne von 0,5 Tag(en) vergangen ... richtiger wäre der Tag heißt '0', und alle Tage danach bekommen die Zahl wieviele vollständige Tage seitdem vergangen sind ... ??? aber da haben sich wahrscheinlich schon schlauere Leute als ich den Kopf zerbrochen.
Problembewußtsein: natürlich ist das 'nicht so wichtig', um 1900 ist wenig für mich oder die heutige Generation wichtiges passiert, nichtsdestotrotz wäre es nett wenn sich die zwei führenden Tabellenkalkulationen auf eine einheitliche Um- und Berechnung einigen könnten ... Meine Vermutung: siehe 'meine Meinung' und 'Problembewußtsein'.

- die Zählung und Behandlung von 'führenden Nullen' ist merkwürdig,
wo ich in Excel mal mit '1' führenden Null eine Anzeige wie '01' erreicht habe mußte ich in LO '2' führende Nullen anfordern, das sind eher keine 'führenden Nullen' oder 'trumps' ('leading zeros'), sondern 'angezeigte Ziffern' oder 'digits to display', in Excel 2010 ist das Auswahlfeld für die trumps weggelassen? Über den 'Format Code' funktioniert alles.
Ich habe damit erstmal kein Problem, es ist so eine 'Erscheinung am Rande' und hier nur als Gedächtnisstütze und zur Abrundung notiert.

Geschichte:

da ich in diesem Forum dort: viewtopic.php?f=6&t=15148&start=10 schon einmal fantastische Hilfe erhalten habe starte ich mal einen Versuch eine gute Sache noch zu verbessern und! nebenbei meine bescheidenen Kenntnisse in LO Strukturen und Makros zu erweitern.

Ich hoffe ich bin hier in der richtigen Rubrik, ansonsten ist jede moderative Hilfe gerne gesehen.

Im obigen thread ging es um das setzen eines Autofilters per Makro, und mir in der Erweiterung um das modifizieren statt setzen, das funktioniert. Ist zwar umständlich, aber funktioniert.

Es gibt aber ein paar 'Merkwürdigkeiten', die teilweise eher genereller Natur sind, und teilweise bestimmt schon anderswo gelöst sind, ich habe! nach den meisten schon gesucht, bisher erfolglos, sonst würde ich nicht fragen sondern die Lösungen hier präsentieren.

Ich habe die Vorstellung daß 'man' das Makro aus obigem thread soweit verbessern kann daß es universell läuft, das würde für mich alleine und mit recherchieren aber zu lange brauchen.

Ich nenne es als Projekt mal 'datasurfer', und es ist bestimmt untypisch hier multi-Fragen zu stellen, wenn jemand einen besseren Ort - eine bessere Methode weiß so etwas zu entwickeln bin ich für jeden Hinweis dankbar.

- verwendetes Betriebssystem: Win7-64 bit,
- Version LibreOffice: Version: 5.4.6.2 (x64)
Build ID: 4014ce260a04f1026ba855d3b8d91541c224eab8
CPU threads: 2; OS: Windows 6.1; UI render: default;
Locale: de-DE (de_DE); Calc: group
- Dateiformat, in dem du speicherst.: ich habs mit *.xls versucht da die Datei so vorlag, wenn unterschiedliches Speichern Einfluss auf die Ausführung von Makros hätte wäre ein grundlegender Hinweis dazu irgendwo mal nötig und hätte ich ihn unterdessen beim Recherchieren mal finden können?
- Denn, wenn du nicht im ODF speicherst, sondern in einem fremden Format,
könnten besondere Schwierigkeiten auftauchen.: könnten: ja, ich dachte aber bzw. mir geht es um eine grundlegende funktionelle Sache, nicht um Frickelkram an Details, der sollte - eigentlich - weitgehend systemunabhängig sein? Ich habs natürlich auch als *.ods versucht ... results the same ... wen wunderts ...

noch eine Bitte, wenn irgendwelche 'Foren-Blockwarte' meinen es sei sinnvoll erst mich 'Foren-Troll' so einzunorden daß ich denke und funktioniere wie sie oder 'die Forennorm', und ich dann natürlich nichts kreatives oder neues mehr beitragen kann ... würde ich mich freuen wenn sie dafür einen eigenen neuen thread aufmachen statt hier herumzuspammen. Im Sinne sinnvoller Foren plädiere ich für weniger kritisieren und mehr Toleranz in Bezug auf die 'Form' und mehr Beschäftigung mit den Inhalten ...

vielen Dank, any help apreciated,



newbie-01

moin,

kleine Ergänzung und erste Rechercheergebnisse:

LO 5.1.6.2 ist in dem Bereich Datumsformate und formatierte Zellen wesentlich 'sauberer' als 5.4.5 und 5.4.6.2, aber weit entfernt von perfect,

Zellen mit führenden Nullen werden auch bei Übergabe vom Filtermakro richtig ausgewertet und angezeigt,

JJ-MM-TT bringt teilweise falsche Ergebnisse, allerdings nur aus dem Makro, bei Nutzung der click-o-mania checkboxen im dropdown-header stimmt die Filterung,

Es gab etwas abweichende Ergebnisse je nachdem ob deutsch oder englisch für die Benutzeroberfläche ausgewählt war, was genau habe ich nicht dokumentiert.

Der 'Konflikt' entsteht zwischen dem aus der aktuellen Zelle gesetzten Wert 'content' der als string übernommen wird und z.B. "14-12-27" heißt, und der mit getfilterfields geholten Variablen afields() die auch als string 'geliefert' wird, aber im Format JJJJ-MM-TT, also z.B. "2018-01-23", und dem das afieldsneu aus content heraus gesetzt wird, und dann afieldsneu als neues Kriterium genommen wird ... ???

Wobei LO wohl die 8-stelligen Datumsformate 'dreht' weil sie für etwas anderes gehalten werden ...

netterweise wird aus dem Makro heraus der 18.01.2018 - angezeigt als 18-01-18 - richtig gefiltert manche anderen Daten auch *lol* - aber! - die clickmania Boxen werden dabei nicht! richtig besetzt, sie bleiben alle leer.

Einschub: ich habe gerade anderswo nebenbei den passenden Ausdruck gelesen wie diese hölzerne Rumprogrammiererei und Rumprobiererei in den calc Makros ist ... sie ist 'nicht! sexy'! ... den mußte ich mal kurz loswerden ...

Daraus - also aus dem vorvorletzten Absatz - folgere ich daß für das setzen des Filters auch das Format mit vierstelliger Jahreszahl 'passend' ist, jetzt muß ich nur noch die variable 'content' vor dem setzen anpassen, allerdings nur! wenn der geholte Wert ein Datumswert ist ... da kann bestimmt jemand mit mehr Erfahrung helfen ...???

Meine ersten Versuche content testhalber 'direkt' zu besetzen liefen in irgendwelche Sackgassen wo - a - der cursor an einer Zelle 'klebt' und man nur noch diese Zelle oder einen Bereich auswählen kann, und - b - wo die Filterung auf 'ohne Inhalt' gesetzt wurde, nicht mehr editierbar war und ich die Tabelle nur über markieren und 'show rows' wieder bearbeitbar kriegen konnte, und - c - wo irgendwelche Filterungen in ganz anderen Spalten gesetzt wurden die 'hängenblieben' aber nicht an den dropdownfeldern sichtbar waren ... leicht nervig.

also da bin ich dann mal wieder an einer Stelle wo ich Hilfe gebrauchen kann, und bedanke mich im Voraus ...

wobei ich nicht völlig hilflos bin ... 2 Stunden suchen und klicken und trial and error ... diese KRÜCKE!!!
tut es für mich in einem sheet wo ich völlig sicher bin daß alle Datumsdaten JJ-MM-TT formatiert sind und! aus dem Bereich 01.01.2000 bis 31.12.2099 kommen ...

(uff, *SchweißvonderStirnwisch* ... ich hatte erst noch angesetzt das umdrehen oder 'spiegeln' des Datumsstrings rückgängig zu machen, was ja Quatsch ist weil es nur passiert wenn das Format 8-stellig ist, nachdem ich das auf 10 Stellen aufgeblasen habe dreht sich nix mehr und brauche ich auch nix zurückdrehen ... also Excel ist ein Unwort! hier im Forum und ich HASSE! Microsoft, aber Excel war! sexyer - oder schreibt man das sexier?)

newbie-01

Hallo,
es ist relativ schwierig sinnvoll zu antworten, da du einerseits grundsätzliche Bedienungs-/Verständnisfragen aufwirfst (vermischt mit einer philosophischen Diskussion darüber, was eine sinnvolle Tabellenkalkulation wäre) und andererseits (das erscheint aber fast nebensächlich) ein konkretes Problem gelöst haben möchtest.
Ich versuche mal:
1) Die Formulierung "führende Nullen" ist ehrlicherweise irreführend da durch diese Einstellung "nur" die (Mindest-)Anzahl der Vorkommaziffern festgelegt wird. (Eine echte Darstellung mit führender Null, egal ob die Zahl ein- oder mehrstellig ist, lässt sich über einen Formatcode aber auch realisieren.)
2) Jedes Datum ist intern eine Zahl. Dazu muss (!) festgelegt werden, welchem Datum die Zahl 0 entspricht. Standardmäßig ist das bei Calc der 30.12.1899. Du kannst in den Optionen aber auch einstellen, dass es der 1.1.1900 oder der 1.1.1904 ist. Letztlich ist es eine (mehr oder weniger) willkürliche Festlegung. Ob es einen tieferen Sinn dahinter gibt, dass Excel mit dem 31.12.1899 startet, weiß ich nicht. Beim Im-/Export von Exceldateien wird es aber meines Wissens beachtet.
3) und nun das eigentliche Problem: Das korrekte Setzen der Filterbedingung per Makro scheint denn doch etwas kniffliger als mit meinem Makro zunächst erhofft. Mal sehen, ob ich es lösen kann.

@mikele,

hi,

es ist weitgehend gelöst, siehe mein posting von 16:16 h,

1. man nehme LO vor Version 5.2.x,

2. man muß die '8-stelligen' Datumswerte etwas tunen,

aber jegliche tiefere Analyse oder elegantere und allgemeingültigere Lösung wäre natürlich nett ...

und ein Hinweis ans Entwicklerteam daß sie da noch irgendwo 'nen bug drinhaben wohl auch sinnvoll ...

beste Grüße,



newbie-01

Hallo,
das Autofiltern scheint dann doch eine recht komplexe Angelegenheit zu sein. Ich gebe mal meine aktuellen Ergebnisse an. Vielleicht kann der ein oder andere (Mit-)Leser seine Erfahrungen oder Erkenntnisse ergänzen.
Der Autofilter erfasst die verschiedenen Einträge der Spalte. Dabei werden
1) Zahlenformate wie "000" ignoriert (die formatierte Zahl 007 erscheint im Autofilter "nur" als 7)
2) zwei Einträge 4,5 (einmal als Zahl und einmal als Text formatiert) als verschieden aufgeführt, aber beim Filtern dann doch beide angezeigt
3) Datumseinträge grupppiert; allerdings nicht, wenn auch die Uhrzeit mit angezeigt wird
4) bei reinen Datumseinträgen - egal wie formatiert - wird als StringValue stets ein Datum im Format "JJJJ-MM-TT" gesetzt (isNumeric ist True, aber NumericValue=0.0 ???)
Schaue ich mir die FilterFields an, so stelle ich erstaunt fest, dass egal ob isNumeric True oder False ist, offenbar stets nur der StringValue benutzt und ausgewertet wird.
Für die Autofilterung per Makro ergibt sich daraus die Frage, wir der korrekte StringValue gefunden wird. Dazu muss der Zellinhalt dahingehend untersucht werden, ob es ein Text, eine Zahl (inkl. Zeiten) oder ein "reines" Datum ist. Weiterhin muss geprüft werden, ob der Anzeigewert eines Zeitwertes ein "reines" Datum ist.
"Reine" Datumswerte müssen dann im Format "JJJJ-MM-TT" als StringValue gesetzt werden. Andere Zahlenwerte können anhand von oCell.Value als NumericValue gesetzt werden, Texte natürlich als StringValue.
Eine allgemeingültige Lösung wird wohl noch auf sich warten lassen ...

hallo mikele,

schön daß eine(r) mithilft!

ich würde gerne schneller antworten, stolpere hier aber von einer merkwürdigen Randerscheinung in die nächste und muß immer erstmal sortieren was hierhin gehört und was 'sonstige Fehler' sind.

zum generellen: hattest du irgendwo geschrieben daß ich zuviel Philosophie, Allgemeines und Konkretes mixe? So sehe ich die Welt, die 'kleinen' Probleme mit denen wir uns herumschlagen sind eingebettet in, und resultieren aus größeren Zusammenhängen, z.B. welcher Programmierer wann seine Pillen nicht genommen hatte ...

zum Ziel: ein allgemein zuverlässig funktionierender 'datasurfer' wäre eine nette Sache, mich kekst daß das in LO wohl nur über die vollständige Begreifung und Behandlung aller Sonderfälle geht, Excel war da sexier ... wenn mir irgendjemand mal erklärt wo die Vorteile der Konzeption von LO liegen wäre ich dankbar, es muss! welche geben, sonst hätte man das nicht so umständlich gemacht.

(wenn nebenbei jemand weiß ob Excel im Hintergrund alle Sonderfälle abhandelt oder einfach vom Filter und Objektkonzept für diese Aufgabenstellung besser paßt fände ich das auch interessant)

zu deinen Zwischenergebnissen:

Autofiltern ... recht komplexe Angelegenheit

jau!

1) Zahlenformate wie "000" ignoriert (die formatierte Zahl 007 erscheint im Autofilter "nur" als 7)

jau, ich meine LO 5.4.6.2 machte damit 'Mist', während 5.1.6.2 das korrekt handelt, ich bin daher zu 5.1.6.2 zurückgegangen

2) zwei Einträge 4,5 (einmal als Zahl und einmal als Text formatiert) als verschieden aufgeführt, aber beim Filtern dann doch beide angezeigt

jau, in 5.1.6.2 etwas verrückt, man kann die zweite 'Erscheinung' in der Filterliste teilweise nicht abwählen, es wird aber nur etwas gefiltert wenn man die erste Erscheinung angeklickt hat, und es gibt 'Zahlen die als Text formatiert sind' bei denen man das garnicht bemerkt oder kontrollieren kann ... alle unter <strg-1> findbaren Formatierungen und der Eintrag in der Zelle sind gleich, trotzdem sind die Zellen irgendwie unterschiedlich, LO macht zwei Einträge in der Filtervorschlagsliste daraus, und Excel bemerkt beim sortieren 'Zahlen die als Text formatiert sind, was soll ich damit machen?'

Beispieltabelle hänge ich an. Ich war nahe am Verzweifeln, man findet die Dinger nicht, eine Bekannte hatte den Tip Suchen und ersetzen von ^*$ durch &, und das hat geholfen, weiß der Teufel um was es da geht netter- und überflüssigerweise funktionieren bei mir seitdem <ctrl-f> und <edit - find> nicht mehr, ... da fehlt doch irgendwie die Aufsicht

Nahe am Verzweifeln bin ich auch weil in meiner Haupttabelle der vom shortcut gesetzte Filter gerne mal 6 Spalten weiter rechts eingetragen wird als die Zelle aus der er definiert wird, da kommt dann natürlich nichts vernünftiges bei heraus, das scheint etwas besser zu gehen wenn man immer nach Öffnen der Tabelle den Datenbereich einmal neu definiert ... es reicht die Definition aufzurufen und zu bestätigen ...

3) Datumseinträge grupppiert; allerdings nicht, wenn auch die Uhrzeit mit angezeigt wird

es mag ja Leute geben die mit sowas besser leben können, ich finde jegliches unberechenbare, komplizierte und eigensinnige Verhalten von Programmen für'n A...

4) bei reinen Datumseinträgen - egal wie formatiert - wird als StringValue stets ein Datum im Format "JJJJ-MM-TT" gesetzt (isNumeric ist True, aber NumericValue=0.0 ???)

das ist der einzige vernünftige Datumsstring! ich habe für meine Bedürfnisse, zur Platzersparnis mit 8-stelligen Formaten zu arbeiten, einen workaround für den FilterShortcut gefunden - den ich unterdessen mal datasurfer nenne -
macht aus '18-02-25' '2018-02-25', und das kann der Filter verdauen ...

ist ganz niedlich, aber wenn die 'Mächtigkeit' von LO nun darauf hinauslaufen soll jeden Spezialfall extra abhandeln zu können ... und zu sollen ... wo Excel mit
alles fertig hat dann zweifele ich allmählich am Sinn der Mächtigkeit. Es wäre mir lieb wenn du dir dieses 'Funktionieren' einmal in Ruhe anguckst und prüfst ob wir daraus etwas lernen können ... .value zu besetzen statt .string, doch 'direkt' in die Filterdefinition zu schreiben ... oder was auch immer

Schaue ich mir die FilterFields an, so stelle ich erstaunt fest, dass egal ob isNumeric True oder False ist, offenbar stets nur der StringValue benutzt und ausgewertet wird.

Das führt zu 'lustigen' Ergebnissen z.B. für Dezimalzahlen die gerundet angezeigt werden (2,83) aber 'länger' sind (2,834) und wo dann durch das Filtern vermittels des strings 2,83 die Zahl sich selber 'rausschießt' ...

Für die Autofilterung per Makro ergibt sich daraus die Frage, wir der korrekte StringValue gefunden wird. Dazu muss der Zellinhalt dahingehend untersucht werden, ob es ein Text, eine Zahl (inkl. Zeiten) oder ein "reines" Datum ist. Weiterhin muss geprüft werden, ob der Anzeigewert eines Zeitwertes ein "reines" Datum ist.
"Reine" Datumswerte müssen dann im Format "JJJJ-MM-TT" als StringValue gesetzt werden. Andere Zahlenwerte können anhand von oCell.Value als NumericValue gesetzt werden, Texte natürlich als StringValue.

davor ergeben sich die Fragen
- ob das sinnvoll ist (oder man die Entwickler mal auf Verbesserungen ansprechen darf),
- ob es noch andere Möglichkeiten gibt (tablefilterfields3 oder sowas?, nur den 'value' der Filtervariablen zu besetzen? ...?),
- und wieviel Spezialfälle wir dann so abzuarbeiten haben (leere Zellen - damit machte der Filter bei mir noch Unsinn, Leerzeichen, Datumswerte, #NA - wäre doch nett wenn man sich alle Problemfälle heraussortieren kann, #Value - dito, da kommt richtig Arbeit auf uns zu ...

Wenn es sinnvoll ist wäre ein Weg über 'case' alle 'numberformats' durchzugehen und jeweils das dafür passende in den string zu schreiben ... eine Höllenarbeit ... und garnicht 'sexy' ...

Eine allgemeingültige Lösung wird wohl noch auf sich warten lassen ...

das ist schade, wir sind ja eigentlich nahe dran ...

vorab schon mal Dank für alle weitere Hilfe ...



newbie-01

moin,

entschuldigt wenn ich euch hier mit meinen halb ausgereiften Ergüssen langweile ... es hilft mir mein Denken und meine Tests zu strukturieren, und ...

! es geht voran !

dieses Makro
tut's schon mal ganz gut ...

wichtig ist noch seine Daten mal zu bereinigen, so 'als Text formatierte Zahlen' sind ein Problem ...

ich bin versuchsweise wieder bei LO 5.4.6.2, von den bisher diskutierten Punkten:

1) Zahlenformate wie "000" ignoriert (die formatierte Zahl 007 erscheint im Autofilter "nur" als 7)
jau, ich meine LO 5.4.6.2 machte damit 'Mist', während 5.1.6.2 das korrekt handelt, ich bin daher zu 5.1.6.2 zurückgegangen

es scheint jetzt auch mit LO 5.4 zu gehen, ob das mehr am LO 5.4, mehr am manuellen 'Nachsetzen' des Kriteriums bei 'isnumeric', mehr am bereinigen meiner Daten oder dem guten Wetter liegt weiß ich nicht,

2) zwei Einträge 4,5 (einmal als Zahl und einmal als Text formatiert) als verschieden aufgeführt, aber beim Filtern dann doch beide angezeigt
jau, in 5.1.6.2 etwas verrückt, man kann die zweite 'Erscheinung' in der Filterliste teilweise nicht abwählen, es wird aber nur etwas gefiltert ...

ich habe meine Daten per Suchen und ersetzen von ^*$ durch & bereinigt, das hat geholfen,

weil in meiner Haupttabelle der vom shortcut gesetzte Filter gerne mal 6 Spalten weiter rechts eingetragen wird als die Zelle aus der er definiert wird ...

das tritt noch auf und nervt, den Datenbereich jeweils einmal beim Öffnen der Datei zu bestätigen ist ein workaround aber nervt,

3) Datumseinträge grupppiert; allerdings nicht, wenn auch die Uhrzeit mit angezeigt wird
es mag ja Leute geben die mit sowas besser leben können, ich finde jegliches ...

wer das erfunden hat ...

4) bei reinen Datumseinträgen - egal wie formatiert - wird als StringValue stets ein Datum im Format "JJJJ-MM-TT" gesetzt (isNumeric ist True, aber NumericValue=0.0 ???)
das ist der einzige vernünftige Datumsstring!

funktioniert (macht aus '18-02-25' '2018-02-25', und das kann der Filter verdauen ...)

Das führt zu 'lustigen' Ergebnissen z.B. für Dezimalzahlen die gerundet angezeigt werden (2,83) aber 'länger' sind (2,834) und wo dann durch das Filtern vermittels des strings 2,83 die Zahl sich selber 'rausschießt' ...

ist mit der Zuweisung von .value für den Filterstring erledigt?

Für die Autofilterung per Makro ergibt sich daraus die Frage, wir der korrekte StringValue gefunden wird. Dazu muss der Zellinhalt dahingehend untersucht werden, ob es ein Text, eine Zahl (inkl. Zeiten) oder ein "reines" Datum ist.

Leere Zellen funzen,
#NA! und #VALUE! auch,
Zahlen auch,
Texte auch,
'Datums' überwiegend (JJ-MM-DD mit dem 'umsetzen', DD-MM-JJ ging schon von alleine? JJJJ-MM-DD sowieso, und andere Formate ... wer 'in den dritten Iden des März am Samstag nach Ostern' in eine Tabellenkalkulation einträgt gehört ...
Datum und Zeit kombiniert habe ich jetzt noch nicht probiert,

Eine allgemeingültige Lösung wird wohl noch auf sich warten lassen ...

'habe fertig', ich hoffe was jetzt noch fehlt sind Details am Rande,

und der Weg der Analyse ... wenn was wo nicht funktioniert:

- man definiere den Autofilter manuell, gehe das Makro Schritt für Schritt mit F8 durch, gucke sich an den richtigen Punkten an was in afields übernommen wird, und arbeite sich dann dahin daß in afieldsneu automatisch das passende gesetzt wird, und kann sich an den bestehenden Beispielen orientieren -

ist ja jetzt gebahnt und erprobt ...

vielen Dank an alle die das nochmal durchtesten, überprüfen und verbessern ...



newbie-01

Hallo,

newbie-01 hat geschrieben: ↑

Sa 7. Apr 2018, 09:19

Problembewußtsein: natürlich ist das 'nicht so wichtig', um 1900 ist wenig für mich oder die heutige Generation wichtiges passiert, nichtsdestotrotz wäre es nett wenn sich die zwei führenden Tabellenkalkulationen auf eine einheitliche Um- und Berechnung einigen könnten ... Meine Vermutung: siehe 'meine Meinung' und 'Problembewußtsein'.

schon Excel selbst unterstützt 2 Datumssysteme - google mal Excel 1900 1904 http://lmgtfy.com/?q=excel+1900+1904.
In der "Frühzeit" der EDV sind häufiger mal Dinge verschieden geregelt worden, mit denen Programmierer heute
fertig werden müssen. Und bei Datumsberechnungen wurde das Thema Säkularjahre oft übersehen.
Nebenbei war das "einigen" mit Microsoft häufig wohl recht schwierig...

Solange Du Excel-Dateien mit Calc öffnest sollte es übrigens keine Probleme bei der Datenübernahme geben, da in jeder
"Arbeitsmappe" vermerkt ist, auf welche Basis Sie sich bezieht (so schlau war Microsoft schon), womit Calc korrekt umrechnen kann.
Was man vermeiden sollte/kann sind Annahmen, welche interne Zahl für ein Datum verwendet wird.

Mfg, Jörn

Hallo,

newbie-01 hat geschrieben: ↑

Sa 7. Apr 2018, 09:19

Problembewußtsein: natürlich sind führende Nullen Quatsch, ich meine sie waren irgendwo (Excel) mal für eine funktionierende Sortierung von Kalenderwochen nötig, und ich benutze sie wenn ich Dateinamen konstruiere die die Kalenderwoche enthalten und vernünftig sortiert im Ordner

das Jahr 1995 ist zwar schon länger her, aber ich erinnere mich, daß bei der Postleitzahlkonvertierung eine Menge Programme
und Routinen erweitert werden mussten, die Postleitzahlen für 4-stellige Zahlen hielten. Und es würde mich sehr erstaunen
wenn heute keine einzige Routine mehr von 5-stelligen Zahlen mit gegebenenfalls einer führenden Null ausgeht.
Es mag ja alles Quatsch sein - aber es ist Quatsch, den kein Software-Hersteller ohne Not einfach abschalten wird, weil es zu verbreitet ist.

Mfg, Jörn

PS: Für eine Sortierung von Kalenderwochen braucht man führende Nullen nur, wenn man zuerst den "Fehler" gemacht hat, die
Zahl in eine Zeichenkette zu wandeln und diese Zeichenketten dann sortieren will.

Kurzform für Schnelleser:

- führende Nullen sind ok, außer trump, und

- Excel kennt einen 29.02.1900 der aber nicht wirklich stattgefunden hat, damit kann Excel erst ab dem 01.03.1900 richtig rechnen.

moin,

@Wanderer:

Hallo Jörn,

ich fühle mich leicht mißverstanden, ich wollte nicht gegen führende nullen lästern (außer gegen trump) sondern mich quasi entschuldigen daß ich manchmal etwas verwende was viele leute nicht verstehen (ich verstehe auch nicht wie man auf trump kommen konnte).

wenn ... diese makrosortierung funzt ja jetzt halbwegs (was aber nicht heißt das ich sie völlig verstanden habe) ... LO beim autofiltern jeweils die ausprägung 'string' der zelle auswertet dann braucht man den fehler 'zahl zu text' nicht selber machen, man braucht sich nur selber wundern.

und wenn ich das was mikele zum Verhalten des autofilters geschrieben hat richtig verstehe (und meine experimente bestätigen das) dann passiert genau das ... LO holt mit 'aFields()=oFilterDesc.getFilterFields' aus einer ausdrücklich als "numeric, two 'leading zeros', negatives red" formatierten Zelle den string '7' in die afields, nicht '07', schreibt es in den 'stringvalue', ordnet es als 'isnumeric = false' ein, und läßt 'numericvalue' leer. nach oberflächlicher betrachtung ist das ein fehler der funktion(alität) oFilterDesc.getFilterFields. zumindestens ein für normale menschen erstmal 'irritierendes verhalten' ... und ich wundere mich.

genauso wie über:

@Wanderer:

Hallo Jörn,

ja, daß es verschiedene zuordnungen datum - zahl gibt ist verständlich, und daß die mit der vergangenheit gewisse schwierigkeiten haben auch, ich weiß nicht ob sich überhaupt zwei gelehrte einigen könnten wieviele tage seit christi geburt vergangen sind, damit wird es schwer die durchzunummerieren - verständlich.

trotzdem wundere ich mich manchmal, und hilft es mir manchmal das aufzuschreiben, und mag es manchmal anderen leuten helfen sich zu orientieren.

für den Zeitraum seit dem 19 Jahrhundert dachte ich daß unser verständnis von zeit halbwegs geklärt sei, und halbwegs genau!, wir beschäftigen uns ja schon mit atomuhren und 'leap seconds'.

warum excel (ver. 2010 in von mir nicht irgendwie bewußt geänderter 'grundeinstellung') der Zahl '0' einen 00.01.1900 zuordnet ist mir nicht erklärlich (ob der im Kalender von windows im gegensatz zu meinem überhaupt stattgefunden hat habe ich noch nicht überprüft, da müßte ich zu lange blättern).

und wenn ich dann so zum 'mich einfühlen' mal andere werte von LO und excel in 'datums' übersetzen lasse ist bei beiden programmen '43202' heute, also der 12.04.2018. wenn man von halbwegs logischen daten ausgeht, von einer gewissen 'gestuften kontinuität' der natürlichen zahlen, von einer ähnlichen kontinuität der verflossenen zeit, davon daß sich weder excel noch LO noch ich schnell genug bewegen als das sich relativitätseffekte deutlich auswirken könnten, davon daß wir uns ungefähr gleich schnell im raum-zeit-kontinuum bewegen ... ich merke es wird zu lang

... dann sollte man doch eigentlich erwarten daß bei beiden programmen die zahl '2' auch den gleichen Tag 'bedeutet ...

tut sie aber nicht!!!

etwas herumprobieren brachte als 'grund' daß für excel ein 29.02.1900 stattgefunden hat, für LO nicht. Nach mehreren Quellen im web hat LO recht, und hat Excel den Fehler 'absichtlich' von Lotus 1-2-3 übernommen um eine höhere kompatibilität zu erreichen ... da fehlt doch irgendwo die Aufsicht.

entschuldigt also daß ich altbekannte Fehler ausgrabe, vielleicht hilft es dem einen oder anderen zu verstehen wie scharf, unscharf, oder schartig die skalpelle sind mit denen wir hier arbeiten ... und ... finger hoch und ehrlich sein ... wer hatte es gewusst? und warum hat man es mir nicht gleich gesagt sondern versucht es auf 'sonstige abweichungen' zu schieben?