Wie markiere ich den ersten von mehreren identischen Begriffen in einer Excel- bzw. Textdatei - mit Regex, AutoIT?

  • In einer Tabelle mit mehreren tausend Zeilen kommen in Spalte D diverse Begriffe nicht nur einmal vor, sondern mehrfach. Ich brauche immer den gesamten Datensatz der Zeile (Spalten A-U), in dem ein solcher Begriff das erste Mal erscheint, die anderen Zeilen muss ich farbig markieren oder an die weiteren gefundenen Begriffe ein # anhängen. Doppelte Einträge zu löschen ist nicht möglich.


    Es soll entweder das jeweils erste Vorkommen von Wasser, Milch, Wein, Bier markiert werden (siehe Bild), oder alle anderen Vorkommen. Alternativ kann auch ein Sonderzeichen wie etwa # an den jeweils ersten gefunden Begriff gehängt werden. Es geht darum, die ersten von den restlichen gefundenen Begriffen unterscheidbar zu machen.

    Da ich nicht weiß, welche Begriffe mehrfach vorkommen, ist eine Suche nach vorher definierten Begriffen unmöglich.

    Wie kann das mit Excel, Notepad++, oder AutoIT gelöst werden? Geht das mit Regulären Ausdrücken? Ich weiß ja nicht, nach was ich suche - nur dass ich die zweiten und weitere Duplikate von den ersten trennen muss.


  • Das geht in Excel.


    1. Lege eine Bedingte Formatierung für die komplette betreffende Spalte an.
    2. Dort nimmst du "Formel zur Ermittlung der zu formatierenden Zellen verwenden"
    3. Dort trägst du dann folgende Formel ein: =VERGLEICH($A1;$A:$A;0)=ZEILE()
      1. Also: =VERGLEICH($Erste_Zeile;$Spalte;0)=ZEILE()
      2. Wichtig sind auch die $ aus 3.!
    4. Wird angewendet auf muss ebenfalls auf die ganze Spalte zeigen. Also in meinem Beispiel: =$A:$A

    Zusatz: Willst du das exakt andersherum (Duplicate markieren), müsstest du das = vor Zeile in ein <> ändern.

    Zusätzlich niemals irgendwas "dran hängen" bei solchen Auswertungen. Damit verfälscht du die Daten, was im Nachhinein zu Problemen führen könnte.

  • Hi!


    Hier ein Codebeispiel, wenn du eine Textdatei hast.

    Trennzeichen ist " " (Leerzeichen)

    $iGesuchteSpalte = 1 (Achtung Array startet bei 0 also 1 wäre die 2 Spalte (B) im Vergleich zu Excel)

    $iAnzahlanSpalten = 2 (mit dem Datensatz von oben gibt es ja nur 2 Spalten ich nehme aber an in deinen echt Daten hast du mehr Spalten)


    Code: Datensatz.txt
    12 Wasser
    14 Milch
    38 Wein
    32 Wein
    14 Wasser
    5 Bier
    41 Wein
    6 Bier
    9 Milch
    33 Milch

    If not :?: then ?( else :thumbup:

    6 Mal editiert, zuletzt von Concara () aus folgendem Grund: Fehler im Code

  • Ich suche in einem Fall nach Dubletten, die ich markieren möchte.

    Erst durchsuche ich die Datei. und fülle ähnlich wie oben beschrieben ein Array. Das schicke ich dann an eine Funktion, die in meinem Fall, die ganze Zeile gelb markiert.
    Ich hoffe das hilft dir schon. Ansonsten antworte und erwähne mich, dann bekomme ich eine Mail.

  • Warum so kompliziert, wenn Excel das selber hergibt?

    Zumal es dann dynamisch ist. Wenn neue Einträge dazukommen, werden diese ohne ein externes Programm laufen zu lassen sofort wieder markiert.

  • Warum so kompliziert, wenn Excel das selber hergibt?

    Frage ich mich bei 98% aller Anfragen zum Thema AutoIt/Excel.

    Mit VBA gibt es so gut wie nichts, was man nicht auch ohne AutoIt hinbekommt. Mit dem Hintergrund, nicht noch ein Zweitprogramm benutzen zu müssen, und dem eindeutigen Vorteil der "Usability und Visuability" von VBA gegenüber AutoIt.


    Und ja, auch ich benutze AutoIt in Verbindung mit Excel. Aber dann eher indirekt. Sämtliche SQL-Abfragen einer externen ERP/DB-Software laufen über VBA und erzeugen Dateien welche dann (per AutoIt "ferngesteuert") von einem Drittprogramm eingelesen und abgearbeitet werden. Das Drittprogramm exportiert wiederum Dateien, welche im Programmablauf vom VBA-Script in Excel eingelesen und visualisiert werden. Als "Abfallprodukt" ermittle ich noch Ablauf-, Kapazitäts- und Bestelldaten für sowohl Kunden als auch das Logistikunternehmen, welche automatisiert per Mail per VBA sowohl an die Kunden, als auch an die Spedition versendet werden.

    Insgesamt sind also vier Softwarepakete im Einsatz um die "händische" Arbeit eines Mitarbeiters von ca. 30 Minuten innerhalb von ca. 30 Sekunden abzuwickeln.

    Und warum?! Weil es die geschätzten Programmierer der ERP-Software seit JAHREN nicht hinbekommen, eine kauffertige Lösung anzubieten.

    Wobei, um fair zu bleiben, "angeboten" hatten die schon des öfteren etwas... :Face:

    Nur passte mein Lastenheft nicht zu deren Pflichtenheft :D

  • Ich kann jetzt nichts über alle Anfragen sagen. Aber die 98% kommen mir einfach sehr hoch vor. Einfach weil ich denke, dass es sehr oft noch Bedarf gibt. Du hast ja wenigstens mit einem ERP zu kämpfen :D Aber so eine Orchestrierung von Programmen im Selbstbau gibt es doch super oft. Selbst habe ich etwa das Szenario, dass im Backend Formulardaten als Email eingehen und erst bearbeitet werden müssen, bevor sie in ein CRM kommen..
    Dazu werden die Mails ausgelesen und in eine Excel Datei geschrieben. Hier werden Mails aussortiert und Datensätze als Dubletten markiert, die nicht zwangsläufig 1zu1 gleiche Datensätze sind und deshalb noch einmal angeschaut werden sollen.

    Man kann darüber lachen. Aber man sollte sich nicht wundern, wenn es nicht irre oft in der Wirtschaft noch so aussieht. Solche Sachen halte ich jedenfalls für relativ häufig und

  • Auch wenn wir jetzt etwas in OT abdriften (der TE möge es uns verzeihen) zeigt sich gerade bei großen Softwarepaketen die 80:20 Regel:

    80% der User nutzen nur 20% des Softwareumfangs - was i.d.R. aber daran liegt, dass das Können der Software nicht auf die Anforderungen der Firma abgestimmt ist (werden kann).

    Woraus aber auch der Umkehrschluss resultiert, dass die Programmierer 80% der Softwareleistung für'n Ar.. erstellen. Was für eine Verschwendung von Ressourcen. :Face:

    Darum Augen auf beim Softwarekauf!

    Unser Warenwirtschaftssystem (oder muss ich jetzt neudeutsch auch CRM sagen? <X ) habe ich selbst aussuchen dürfen. Es ist jetzt über 20 Jahre alt und läuft genauso frisch, wie am ersten Tag. Da gibt es keinen großen Schnickschnack. Nur die Basisfunktionen. Aber wenn ich was erweitern will, habe ich Zugriff auf ein internes Basic-System und natürlich auf die SQL-Schnittstelle. Der einzige Nachteil, ich muss eine Hardware vorhalten, die noch Windows 2000 Server kann. Aber das war bis jetzt kein größeres Hindernis. Und da das System in einem Intranet läuft, können mir zum Glück irgendwelche Sicherheitslücken der letzten 20 Jahre aber sowas von egal sein. :D

  • Auch wenn wir jetzt etwas in OT abdriften

    Ich bin davon überzeugt, dass Beiträge von Leuten, die Ahnung von dem haben was sie tun, hilfreich sind.

    Vielleicht nicht unbedingt für den TE, aber doch für den einen oder anderen der in der Lage ist, über den Tellerrand zu schauen und sich auf diesem Weg weiterzubilden...


    Woraus aber auch der Umkehrschluss resultiert, dass die Programmierer 80% der Softwareleistung für'n Ar.. erstellen. Was für eine Verschwendung von Ressourcen.

    DAS sollten sich aber auch mal SÄMTLICHE Software-"Ersteller" sowas von hinter die Ohren schreiben! Und nicht nur die!

    Wobei aber immer hinterfragt werden sollte, aus welchem Grund der/die Programmierer 80% der Funktionalität "umsonst" erstellt. Antwort: weil er schlichtweg absolut keine Ahnung von dem hat, was er dort tut/tun soll!

    Wie auch, denn sein Job ist, die meist nur vage formulierten Vorgaben von Leuten, die meist auch nur wenig Ahnung von den konkret ablaufenden Prozessen haben, in Software umzusetzen.

    Und das macht er dann auch! Und zwar so, wie ER es für richtig hält. Da wird dann auch mal (kein Witz jetzt, Beispiel aus der Praxis) anstatt den Kunden nach den fachspezifischen Vorgängen/Termini zu fragen, "mal eben" ein Wikipediaartikel hergenommen um überhaupt zu verstehen, um was dem Kunden VIELLEICHT geht. Um im Anschluß daran ein Softwaremodul zu präsentieren, das in keinster Weise funktioniert.

    Diskussionen bis hin zur Geschäftsleitungsebene, die aber (beide, sowohl Auftraggeber als auch SW-Ersteller) wiederum gar nicht wissen, was überhaupt erreicht werden sollte.....

    Daher auch mein Hinweis zum Lasten- und Pflichtenheft. Vgl. die Grundsätze von "agilem" Projektmanagement und/oder "Voice of the Customer" bei 6Sigma.


    Ich hatte auch schon mit meiner liebreizenden Art den Geschäftsführer eines (weltweit tätigen) Softwareunternehmens zur Weißglut gebracht, weil ich immer wieder darauf hingewiesen hatte, MEINE Vorgaben GENAU SO WIE BESCHRIEBEN umzusetzen. Und nur genau diese Umsetzung wird dann auch bezahlt....

    Und genau hier liegt der Hase im Pfeffer! Der Ablauf beim Softwareersteller ist nämlich folgender: Lastenheft anschauen, grobe Peilung Machbarkeit/Umsetzung/Zeitplan ermitteln und Angebot abgeben mit (gesalzenem) Preis.

    Nach Auftragseingang Projekt nach hinten schieben (ist doch eh nur pillepalle und ausserdem haben wir noch genug Zeit...) und dann auf der letzten Rille loslegen.

    Die Umsetzung der Vorgaben wird auch nicht mit dem Kunden besprochen, dafür ist keine Zeit und der Kunde könnte merken, dass es nicht vorwärts geht!

    Stattdessen wird sich etwas aus den Fingern gesaugt (wird schon so hinhauen...) und Praxisfern umgesetzt. Bis der Kunde merkt, dass er das in Auftrag gegebene Modul so nicht anwenden kann, ist es zu spät. Der Softwareersteller will seine bisherige und unnütze Arbeit bezahlt haben, und der Kunde ein anwendbares Produkt. DAS kann nur zu Unzufriedenheit bei beiden führen....



    Ich kann jetzt nichts über alle Anfragen sagen. Aber die 98% kommen mir einfach sehr hoch vor. Einfach weil ich denke, dass es sehr oft noch Bedarf gibt.

    Relativiere mal die 98%....

    WER fragt an? Derjenige, der von Excel/VBA keinerlei Ahnung hat. Und auch nicht von AutoIt! Hätte er von einem von beiden Ahnung, würde er nicht fragen, sondern hätte eine Lösung!

    Keine Ahnung von irgendetwas zu haben ist ja per se nicht das Problem, das Problem liegt meist im Bereich X-Y.

    Der Frager "denkt" sich wie die Lösung aussehen könnte, fängt damit an, kommt aufgrund mangelndem Knowhow nicht weiter und anstatt sich zu ins Thema einzuarbeiten wird dann panisch kurz vor Angst Aktivismus in Form von diversen Forenanfragen geübt. Und da soll das "Problem" jemand lösen, der mangels adäquater Beschreibung auch keine Ahnung von dem hat, was der Frager benötigt.

    Vergleiche DAS mal mit dem im oberen Absatz beschriebenen Ablauf bei einem SW-Unternehmen.....identisch!

    Der "Anwender" ist von seiner Denke her genauso beschränkt wie der "Programmierer".

    Und wenn da der eine Blinde dem anderen Blinden über die Straße helfen soll, muss man sich nicht wundern, wenn das in die Hose geht....und auch mal RICHTIG Geld kostet, s. bspw. HIER . Wenn man sich mit den im Artikel beschriebenen Vorgängen beschäftigt stellt man schnell fest, dass das Problem nicht die "Standard"-Software ist, sondern die Umsetzung/Erweiterung auf die kundenspezifischen Prozesse.


    Analog zum Problem des TE....nicht Excel ist das Problem, sondern die vermeintlich "so" nicht umsetzbare "Lösung" des Anwenders...



    die 80:20 Regel:

    ....besagt, dass es, würden die 80% ihren Job auch richtig machen, kein Problem gäbe ;)

    Pareto ftw! :rock: