Beiträge von bazii

    Was habe ich nun also getan:
    Ich habe das ausführbare Script (.au3) File auf Öffnen Mit -> 64 Interpreter umgestellt.
    Ich habe davon eine Verknüpfung erzeugt und an einen anderen Ort verlegt (vermutlich ist das nicht nötig aber es läuft).
    Dann habe ich ein Batch - File erzeugt die auf die Au3.lnk verweist, erzeugt und im Autostart hinterlegt.

    Das wirkt auf mich kompiziert und Fehleranfällig.

    Dieses Verhalten konnte ich mit der Windows Aufgabenplannung / PSEXEC als auch mit BATCH nachstellen.


    Nur ein Hinweis am Rande, da die Aufgabenplanung Batchdateien nicht zuverlässig interpretieren kann. Und das mit "cmd" noch mit "bat" - Dateien. Leider habe ich damit schon zermürbende Erfahrungen gesammelt. Kompiliere am besten das Skript und verwende die .exe Datei in der Aufgabenplanung und du wirst sehen dass das recht zuverlässig funktioniert.

    Ich gelobe Besserung.

    Bitte entschuldige meinen Senf aber da gibt es von Dir nichts zu bessern. Alle Beiträge bringen in dieses Thema Verbesserungen ein. Ich hab' schon viel durch Beitrge von Dir erfahren und gelernt. Deine Verhaltensweise ist einwandfrei. Außerdem ist man nicht jeden Tag gleich gut drauf. Niemand hier kann von sich behaupten, immerzu die Lösungen auf Anhieb bereitzuhalten oder erarbeiten zu wollen. Es sind meist Denkansätze und Codebeispiele, die uns alle weiterbringen könnnen wenn wir denn möchten.

    Ist nur schade, dass niemand anderes hier im Forum eine Idee dazu hat.

    Ideen und Anreize gab es definitiv. Nur wenig bis keine Reaktionen auf die gegeben Hinweise. Bitte nicht falsch verstehen *.

    Da, außer mir, scheinbar niemand mit dem Problem "ScreenUpdating" unter AutoIT zu tun hat/hatte, schließe ich hiermit dieses Thema und lasse es halt "flackern".

    Zu Deinem Problem AutoItler:
    Es wäre IMHO von Vorteil zur Hilfestellung, wenn Du vorab erzählt hättest, was bereits im Detail zur Lösung des Problems unternommen wurde.


    Ich selbst würde mir zunächst kein Skript in Autoit erstellen um das Problem zu umschiffen, sondern zunächst ersteinmal ein neues Benutzer-Profil zum testen erstellen und schauen, ob dann das Problem noch besteht. Falls ja, irre ich mich. Falls ein neues Benutzerprofil hilft, würde ich es einrichten und fertig.



    * Klasse wäre es, ein klitzekleines Feedback "nur" zu den Lösungsvorschlägen aller Beiträge zu bekommen, die Du erhalten hast und vollkommen sachlich waren/sind.

    Das heißt, du kannst ruhig ohne Löschen der DB in Verzeichnissen suchen. Wenn dir die Suchen träge erscheinen kannst du mit "Datenbankbereinigung" alle obsoleten Daten löschen.

    Na, das ist doch echt genial. Dann nutze ich doch das richtige Programm :thumbsup: und kann es jetzt, nachdem Du den Fehler gefixt hat auf allen Partitionen nutzen und somit in der Datenbanksuche und gleichsam mit genauer Trefferquote enorm viel Zeit sparen.

    Das ist aber auch eine große Schwäche des Programms. Hier hast du bisher keine Möglichkeit nur bestimmte Daten zu entfernen. Alles was nicht zur aktuellen Suche passt, fliegt raus.

    Man muss ja nicht unbedingt Daten daraus entfernen. Solage die Datenbank nicht spürbar träger wird, wenn sie immer voller wird finde ich das voll ok so wie es ist.



    Statt dem Bearbeitet-Zeitpunkt habe ich den Erstellt-Zeitpunkt ausgewertet und immer mit dem Wert in der Datenbank verglichen.

    Eben habe ich von 7268 indexierten Dateien bei denen ein Suchwort vorkam, in einer der gefundenen Dateien das Suchwort geändert.
    Resultat (ohne nur Datenbanksuche) war in 24 Sekunden perfekt. Die Datei wurde nicht mehr gefunden. :klatschen::thumbsup: . Klasse Arbeit !

    gerade erledige ich eine ...

    tut mir echt leid ;( .... ich konnte nicht im entferntesten ahnen was ich Dir damit antue. ||

    Danke für die Info. Ich hatte das Programm bereits mehrfach sehr erfolgreich im Einsatz, hatte den Fehler aber nicht entdeckt, da ich die Datenbank für meine Suchen stets entleert habe, da die verschiedenen Suchordner immer auf einer anderen Festplattenpartition waren. Hier auch gleich die Frage, wie sich das mit solch verschiedenen Suchorten verhält. Wie reagiert da die Datenbank, wenn ich diese nicht entleere? Was ist sinnvoller in diesem Fall meine ich. Besser DB leeren oder nicht, wenn die Suche auf verschiedenen Partitionen stattfindet?

    Hier wäre vielleicht grepWin etwas für dich: stefanstools.sourceforge.net/grepWin.html

    Das kenne ich bereits. Kein Programm aber das ich kenne bietet mir das was ich alles vereinen möchte.

    Text ersetzen kann ich in Office-Dateien nicht ohne installiertes Office.

    Das habe ich nie für ein Problem gehalten, da ja auch mit einem Open- oder Libreoffice die Dateien geöffnet und bearbeitet werden können. Kann mich aber auch täuschen.

    Die Forensoftware nennt mich zwar Profi, aber

    und mich Fortgeschrittener .... Ich habe schon ein paar nützliche Dinge gecodet aber brauchte immer Hilfe weil ich irgendwann nicht mehr weiter wusste.



    Ansonsten kann ich dir sicher die Suche in dein Programm einbauen. Aber ohne Datenbank in dem Fall, oder?

    Das ist es ja, ich kann das nicht richtig beurteilen.
    Mein Programm sucht und findet Text und kann ihn auch ersetzen.


    Dein Programm sucht und findet Text und kann die Dateien auf verschiedene Weise anzeigen.


    Vereint wäre das klasse. Ob eine Datenbank dazu notwendig sein muss kann ich nicht beurteilen. Fehler ist es aber sicher nicht oder was meinst Du?


    In mein Skript sollte noch die Funktionalität von Zip, 7z. entpacken, Text suchen, finden, ersetzen und die zuvor entpackten dateien wieder packen integrert werden. Das habe ich nicht geschafft.
    Und Textersetzen von Officedateien sollte halt auch möglich sein. Zur Not auch nur dann, wenn Office installiert ist.

    Mir ist nicht klar, warum das Schreiben so lange dauert (bei den 489 Dateien waren es ja über 0,2 Sekunden je Datei. - So schnell durchsucht das Programm später die ganze Tabelle ). Aber das ist wohl einfach so.

    Mir leutet es ein, warum die Erstsuche (Indexizierung) seine Zeit benötigt. Jede Datei einzeln öffnen, suchen, finden, schließen. Das benötigt seine Zeit. Wie gesagt, mir ist nicht schnelleres als Deine Softw. bekannt.


    Bei mir ist ist die Suchdauer bei 5841 Dateien um etwa 10-15 Sekunden gestiegen (dennoch nur max 66 Sekunden mit SSD).

    Ich arbeite auch mit einer SSD :). Beim zweiten Durchlauf komme ich auch auf Deine Werte. Nur beim ersten Durchlauf nicht. Ich vergleiche den ersten Durchlauf mit einem Indexizieren der Dateien auf Inhalt. Dann geht die Post aber so was von ab, das ist fantastisch. Auch andere Suchbegriffe sind schneller gefunden wie man schauen kann. Schlecht für Pausenliebhaber die ab und an mal wegen der Technik eine rauchen gehen konnten :)


    In deinen Tests habe ich zwar keine Suchtreffer aus Office-Dateien gesehen, aber das funktioniert, oder?

    Das funktioniert aber so was von perfekt. Rechtklick und Libre öffnet die Datei. Doppelklick öffnet das Textfenster in nullkommanix.

    Mein Programm ist vor allem dann sinnvoll, wenn aus Performance-Erwägungen der Indexdienst abgeschaltet ist, oder die Dateien auf einem Netzlaufwerk liegen oder eben kein geeignetes Anzeigeprogramm verfügbar ist.

    Oh ja. So ist es. Vor allem bei älterer Hardware habe ich grundsätzlich den Indexdienst deaktiv. Da leistet Deine Textsuche perfekte Arbeit.


    Wenn du noch eine Idee hast, immer her damit.

    OHA. Das ist eine gefährliche Sache bei mir. Ich muss Dich ausdrücklich davor warnen mich mit Ideeen aufzufordern. Davon habe ich mehr genug. Daraus könnte eine leicht aufwendige Arbeit werden.


    Einiges habe ich aber schon zusammengestrickt. Nur wie, ist eine andere Sache ;( . Und wie Du es dann umsetzen könntest auch. Ich schaffe das alleine nicht.


    Mein Traum ist ein Text-Regenerator. Text suchen, Text finden, Text ersetzen. Incl. Office-Dateien und incl. gepackter Dateien. :thumbsup:
    Hier mein Skript, welches nicht optimal läuft da 7z., zip nicht funktioniert.
    Es könnte entsprechend auf Deine Textsuche erweitert werden könnte oder anders herum. Doch ich packe das alleine einfach nicht.
    Ich habe mich auch nicht getraut, im Forum hier nach entsprechender Unterstütz zu fragen weil ich oftmals die Tips nicht umsetzen kann die ich bekomme.
    Oft brauche ich Tage um 2 zeilen Code funktional zu bekommen. Mir fehlen die Hintergründe eines Studiums oder die Gehirnwindungen. Auch egal.
    Hier der Code:


    Also wenn Du Dir ein wenig Zeit für die Idee nehemn kannst, wäre das klasse :) Quasi ein Gemeinschaftsprojekt.


    Ich bin Gärtnermeister und äußerst kreativ im "planen" aber wesentlich zu naiv (oder zu doof), die wichtigsten Dinge im Code hinzubekommen. Bernd670, Oscar, Autobert, UEZ und nicht zuletzt MakeGrafik haben sich an mir die Zähne bereits ausgebissen, weil ich immer gleich die Hand abreisen will, wenn mir jemand den Finger hinstreckt. :/


    Und diese Idee wäre nicht die einzigste. Hätte da noch eine .... ;( zündende ....

    Im Anhang mal eine angepasste Variante. Ich fände es super, wenn du es mit dieser noch einmal probierst.

    Diese Version ist wieder richtig klasse geworden. Vielen Dank dafür !


    Ich habe jetzt mal zum Test nur einen kleineren Teil meiner Dateien einlesen lassen. Das sind unter 500 Dateien. Enthalten sind nur "doc, docx, xls, xlsx und pdf" Dateien. MS-Office ist auf dem Testrechner nicht installiert. nur Libreoffice. Das sollte ja aber keine Rolle spielen.


    Hier ein Video von dem Versuch unter 500 Dateien mit Konsolenausgabe:
    http://www.eibenkunst.de/Autoi…17_05_25_18_54_20_103.mp4


    Die Fehlerausgabe der Console zeigt auf die entsprechende Dateien wie z. B.:
    Skriptzeile: 1399 D:\xxx\xxx\xxx\xxx\Protokoll xxx 19.12.12.doc - _Word_DocOpen-Fehler: 1


    Allerdings wird dieselbe Datei unterhalb des Fehlers nochmals in der Consolenausgabe ohne den Fehler "_Word_DocOpen-Fehler: 1" ausgegeben.




    Bei einem Test mit wieder mehr als 8.000 Dateien läuft das Skript nun sauber durch. Gefällt mir klasse. Dauer beim Erstdurchlauf mit allen möglichen Dateitypen ca. 13 Minuten. Das sollte im Regelfall aber eher die Ausnahme darstellen meine ich. Siehe: http://www.eibenkunst.de/Autoi…17_05_25_19_15_17_588.mp4


    Die Suchresultate sind sehr gut. Eine andere von mir eingesetzte Software fand auch nicht mehr als Deine, dafür war Deine schneller. Vor allem im Hinblick auf die Datenbanksuche gibt es nichts besseres, zumindest nicht was ich jemals gesehen hätte. Von meiner seite her läuft Dein Skript jetzt sehr gut durch und bietet fast alles was ich für einen sehr guten Suchlauf benötige.


    Ich danke Dir sehr für die Überarbeitungen.

    Mir ist nämlich schleierhaft, warum das Schreiben der DB so lange dauert. Vielleicht werden Nicht-Textdateien eingelesen? Du könntest mal die Einträge aus der "unterstützte Textdatei-Typen.txt" löschen und nur txt darin belassen. Aber das ist ins Blaue geraten.

    Ich kann das morgen Abend gerne testen wenn ich von der Arbeit wieder zu Hause bin.

    Auch der Fehler mit der Fortschrittsanzeige kommt mir spanisch vor. Das ist ein Client-Fenster. Ich dachte das bleibt automatisch vor dem Parent. Aber bei dir sieht es ja so aus, als verschwinde es hinter dem Hauptfenster und erscheint erst wieder nachdem es aktualisiert wird?!?

    Der Fortschrittsbalken bleibt auch vor dem Fenster. Bei 500 DS kein Problem. Nur beim einlesen von 1.000 verschwindet es. Bei 1.500 wird es wieder angezeigt. Bei 2.000 auch.
    Ich muss schauen dass ich mich in den Code einlese. Vielleicht kann ich erkennen an was es liegen kann.

    Ich habe schon mal die Version mit den gewünschten Funktionen fertig und habe zusätzlich noch zwei Fehler gefunden.

    Hey super. Danke für die Mühe.

    Gerade bei sehr vielen Dateien hatte das Programm noch die Schwäche, dass bei der Suche nach Dateien noch kein Feedback kam. Das wollte ich hier auch verbessern und unten links im Hauptfenster läuft ein Zähler für die gefundenen Dateien mit. Hast du das übersehen und sollte der Zähler bei der Fortschrittsanzeige liegen, oder ist dort unten auch kein Zähler sichtbar gewesen?
    (Allerdings dauert dieser Schritt bei mir im AutoIt Verzeichnis bei 5841 Dateien und SSD nur ein, zwei Sekunden. Auf nem Firmenserver-Verzeichnis wo etwa 5700 xls-Dateien liegen komme ich auf etwa 9 Sekunden. Daher müsste da irgendein Problem aufgetreten sein).
    Oder wurde überhaupt irgendwann während der Suche die Progressbar aktualisiert, oder hast du gestartet und irgendwann wurden einfach Ergebnisse gezeigt?
    Wäre super, wenn du das nochmal nachstellen kannst und vielleicht Bedingungen erkennst, wann das passiert. Das würde mich sehr interessieren.


    Danke für Dein Feedback.


    Ich habe Dir zum besseren Verständnis ein Fünfminütiges Video aufgezeichnet, dass Dir mehr Aufschluss über das "scheinbare" Einfrieren geben kann.


    -Achte bitte nach 500 Dateien auf den Fortschrittsbalken. Bis dahin ist alles bestens.
    -Nach 1.000 Dateien sieht es schon anders aus. Kein Forschrittsbalken mehr zu sehen.
    -Aber nach 1.500 Dateien wieder ein Forschritsblaken sichtbar.
    -Nach 2.000 Dateien (am Ende vom Video) zeigt das Proggi "keine Rückmeldung" mehr an. Es suggestiert dem Benutzer ein einfrieren der Softw. doch es ist anders. Es läuft tadellos weiter bis zum Schluss.


    Nach ca. 18 Minuten war das Einlesen der ca. 8.000 Dateien beendet. (Erster Start nach neu entpackten Programmdateien).


    Datenbanksuche war hinterher in 0,3 Sek. absolut erfolgreich.


    Meine Arbeitsumgebung zum Test ist ein Notebook mit Win10 x64 und 8GB Ram ohne jedliche im Hintergrund laufende Sonderanwendung bis auf das Aufzeichnungsprogramm.


    Link zum Video:
    http://www.eibenkunst.de/Autoi…17_05_24_17_23_49_226.mp4 (IE oder Edge nutzen ! Firefox öffnet mir das Video leider nicht.)

    Suchbegriffe lassen sich bisher einzeln mit Entf löschen und die Datenbank wird nur gelöscht, wenn man das Startverzeichnis ändert und Datenbankbereinigung bei der nächsten Suche aktiviert hat. Letzteres finde ich selbst auch schwach.

    Schwach finde ich es gar nicht. Ich selbst habe aber die Vorliebe zur Spurenbeseitigung nach einer Schlagwortsuche. Das spielt ja aber bei der Bereinigung der DB weniger eine übergeordnete Rolle.
    Danke für den Tip mit der "Entf.-Taste". Das hatte ich schlichtweg übersehen, dass wenn ich bei der Auswahl des Suchtextes in der geöffneten Dropdown Liste das Wort markiere, den Suchtext löschen kann.

    Mein Feedback als begeisteter Nutzer von Deiner Textsuche:


    -Die neue Option funktioniert sehr gut. Ae, oe und ue werden , wenn angehakt bestens entdeckt.
    -Das Durchsuchen von 8.200 Textdateien auf ein Schlagwort hat beim 2ten Mal nur 40 Sekunden samt Trefferanzeige gedauert. Beim ersten Mal war über Minuten hinweg kein Fortschritt zu sehen. Das Programm war aber nicht eingefroren. Das kann man ja gut am Festplattenzugriff erkennen.


    - Klasse würde ich zusätzlich finden, wenn die Liste der bereits gesuchten Stichworte mit einem Klick in der Gui gelöscht, als auch die Datenbank auf den Auslieferungszustand bereinigt werden könnte.


    Insgesamt kann ich mich nur wiederholen. Tolle Sache Dein Proggi und absolut funktional. Sehr gute Arbeit. Vielen Dank dafür.

    Dies ist ein sehr hilfreiches und zuverlässiges Werkzeug. Vielen Dank für die Bereitstellung des Quellcodes. Was mit besonders gut gefällt ist die einfache Bedienmöglichkeit des Kalenders im Bezug auf die zu ändernde Datei.


    Eine Frage: Bei jeder Datei die ich anklicke erscheint ein Infofenster mit dem Inhalt Attribute A. Wofür ist das gedacht?

    Hallo Hingo,


    ist das Thema hier nun erledigt? Es geht meiner Meinung nach um das gleiche und fast um das selbe Thema. alpines hat Dich bereits darauf angesprochen, das Thema auf gelöst zu setzen.

    Damit ich den Speicherort ändern kann muss ich doch _InitPDF(@ScriptDir & "\getmac.pdf") und $getmac = @ScriptDir & "\getmac.txt" ändern, oder?

    Ich habe Dir noch ein Beispiel erstellt ;) . Vergleiche am besten mal die Skripte. Tip: In Notepad ++ kam man ein Plugin mit dem Namen "compare" installieren. Damit lassen sich zwei Scripte prima miteinander vergleichen.



    Neu mit Speicherpfad c:\logs\


    2. Speicherpfad im Ausführungsverzeichnis:

    Sollte jetzt jemand um die Ecke gelaufen kommen und behaupten das Techno doch EDM sei dann vergesse ich mich!

    :rofl: Na ja, wir sind ein deutsches Forum hier und das da sich EDM von Techno in DE kaum bis gar nicht unterscheidet (im Gegensatz zur USA) ist das UgaUgaUgaUgaBummBumm für mich Techno. :ironie: