Ordnerinhalt inkl Unterordner in eine Text Datei speichern

[NicTheQuick]

Man kann das auch iterativ machen, indem man eine LinkedList als Stack nutzt und dort einfach immer alle neuen Ordner einreiht, die noch enumeriert werden müssen. Neue Ordner werden hinten angehängt und vorne abgeholt, wenn die nächste Enumeration starten soll.

[ts-soft]

Noch was ganz anderes:

Code: Alles auswählen

 Define.i hwndEdit, LineCount, hdc, fsz.SIZE, eRect.RECT

Code: Alles auswählen

Define.i Any, NewDir$, File$

Erstens wäre es Syntaktisch richtiger, nicht Define.i sondern Define zu nutzen, da ja auch nicht Integer deklariert werden,
z.B. fsz.SIZE oder NewDir$
PS: besser für jeden Typ eine neue Zeile! Ist übersichtlicher.

Außerdem ist es in einer Procedure im allg. besser Protected statt Define zu nutzen. Hab aber jetzt keine Lust, das
nochmals zu erklären.

Das ist jetzt aber nur Meckern auf hohem Niveau

[udg]

Noch was ganz anderes:
Außerdem ist es in einer Procedure im allg. besser Protected statt Define zu nutzen. Hab aber jetzt keine Lust, das
nochmals zu erklären.
Das ist jetzt aber nur Meckern auf hohem Niveau

nein passt schon. Immer her mit den Infos. Ich habe das geändert und muss sagen, warum auch immer, läuft sogar beim Erstellen der txt Datei ein paar Millisekunden schneller.

Edit:
es ist nicht schneller auch wenn es mir so vorkommt. Zumindest bei dieser Sache hier. Bei anderen, spielen Millisekunden schon eine Rolle. Ist dann aber eine andere Geschichte

[NicTheQuick]

Schneller wird dadurch aber nichts. Auch sonst brauchst du aber bei Dateisystemoperationen nicht anfangen Vergleiche auf Millisekundenbasis anzustellen.

[Sicro]

Ich habe gerade mal kurz getestet, wie viele rekursiven Aufrufe durchgeführt werden können, ohne dass das Programm abschmiert.
Ergebnis: 130934 rekursive Aufrufe. So eine Unterverzeichnistiefe hat sicherlich niemand auf seinem PC, daher sehe ich die Vorgehensweise mit rekursivem Aufrufen in diesem Fall für unbedenklich.
Möglicherweise variiert die maximale Anzahl der rekursiven Aufrufe bei unterschiedlichen PCs.

Test-Code:

Code: Alles auswählen

Global.q counter = -1 ; Der erste Aufruf ist ja nicht rekursiv, daher Startwert "-1"

Procedure a()
  counter + 1
  FileSeek(0, 0)
  WriteString(0, Str(counter))
  a()
EndProcedure

path$ = GetTemporaryDirectory() + "testdata.txt"
If Not CreateFile(0, path$, #PB_File_NoBuffering)
  MessageRequester("Fehler", "Testdatei konnte nicht erstellt werden!", #PB_MessageRequester_Error)
  End
EndIf
a()

[PureLust]

Hallo udg,

zuerst einmal:
Mit dem Design hast Du Dir wirklich Mühe gegeben - sieht sehr gut aus.
Wenn nun noch die Funktion dem Design standhält wird's perfekt.

Anbei noch ein paar Tipps:

1. Nachdem ich einfach mal auf "Starten" geklickt und den File-Requester dann abgebrochen hatte, dachte ich zuerst dass das Programm komplett abgestürzt sei, da keine Reaktion mehr erfolgte.
Nachdem ich mir dein Programm mal etwas näher angeschaut hatte, war klar was passierte.

Deine Examine() Routine versuchte, alle Namen meiner ~542.000 Dateien auf meiner Platte auszulesen und in eine Text-Variable zu speichern.
Zu Text-Variablen solltest Du wissen, dass diese in PB unter bestimmten Bedingungen extrem langsam verarbeitet werden.
Und je mehr Zeichen eine solche Variable enthält, desto langsamer wird die Verarbeitung.

Ich habe Dein Programm nach etwas über 20 Minuten abgebrochen, wobei die Text-Variable zu diesem Zeitpunkt rund 34 MB Speicher in Anspruch genommen hat.
Bei jedem weiteren Eintrag mussten also zuerst ~34 MB Daten verarbeitet werden ... und es wären noch gut 80 MB an weiteren Daten hinzu gekommen.
In Anbetracht dessen, dass die Routine mit größer werdender Datenmenge immer langsamer wird, dürfte das Einlesen geschätzte 2-3 Stunden gedauert haben.
Wie Du siehst - nicht wirklich praktikabel.

Du solltest Dir vielleicht nochmal den Hinweis von TS-Soft bzgl. der LinkedList anschauen.

Ich habe Deine Examine() Routine mal probehalber auf eine LinkedList umgebaut, und das Einlesen von ~542.000 Dateien mit einer Textmenge von ~117 MB war nach knapp 8 Sekunden (ja ... 8 SEKUNDEN) beendet.
Wie Du siehst ... ein 'kleiner' Unterschied zu voraussichtlichen 2-3 Stunden.

Ich wollte Dir jetzt aber hier nicht einfach meinem Code posten, um Dir nicht den 'Spaß' beim selber herausfinden zu nehmen.
Solltest Du aber nicht klar kommen, dann kannst Du gerne nochmal fragen.

Aber mal so als Starthilfe:
- eine globale LinkedList erstellen (mit String-Variable)
- statt den aktuellen Directory-Eintrag an den bisherigen Text anzufügen, ein neues LinkedList Element erstellen und den Text dort speichern (also jeder Directory-Eintrag in ein neues LinkedList-Element).
- später, beim speichern, einfach alle Elemente der LinkedList mit einer ForEach-Schleife durchlaufen und deren Inhalt Zeile für Zeile abspeichern.

Solltest Du schaffen können.

2. Wie ich ja oben bereits geschrieben hatte, habe ich den Speichern-Filerequester abgebrochen.
Dies hat zur Folge, dass später bei Speichern die Fehlermeldung "Konnte Datei nicht erstellen!" ausgegeben wurde.
Aber eben erst NACHDEM die Dateien eingelesen wurde.
Was glaubst Du wie ärgerlich das für den Anwender ist, wenn er (bei der jetzigen Geschwindigkeit) mehrer Minuten oder gar Stunden wartet und am Ende dann gesagt bekommt, dass die Daten nicht gespeichert werden konnten.
Hier solltest Du also das Ergebnis der Filerequesters besser abfragen und prüfen ob Du in die angegebene Datei überhaupt schreiben kannst bzw. ob eine vorhandene Datei überschrieben werden soll.
Und das ganze natürlich BEVOR Du mit dem aufwändigen Sammeln der Daten beginnst.

3. Wie Du ja selber schon bemerkt hast, kann man auf "Starten" klicken bevor ein Verzeichnis ausgesucht wurde.
Da ein 'DisableGadget()' für Dich nicht in Frage kommt, könntest Du Dir ein Flag (also eine Variable) erstellen, in der Du speicherst ob der Benutzer bereits ein Verzeichnis gewählt hat und dieses Flag in Deinem #Button_Start-Event abfragen.
Weiterhin könntest Du im #Button_Start-Event den Inhalt vom StringGadget(#String_Path,...) auslesen und prüfen ob sich dort eine legaler Pfadangabe befindet.

4. Zum 'Progress':
Ein Progress-Balken fällt ja aus bereits beschriebenen Gründen flach.
Aber Nichts ist schlimmer für den Anwender als wenn er irgendwo klickt und kein Feedback bekommt ob sich was tut.
Um den User zu informieren was gerade geschieht, könntest Du z.B. in einem Textfeld das aktuell bearbeitete Verzeichnis (ggfl. in gekürzter Form) ausgeben. Dann würde der User sehen dass das Programm arbeitet. (Ähnlich der Such-Anzeige im 'TotalCommander' - falls Du das Programm kennst.)

So, ... das soll's aber jetzt erst mal gewesen sein.
Ich hoffe Du kannst was mit den Tipps anfangen.

Wünsche Dir und auch allen anderen PBlern 'nen guten Rutsch und ein glückliches und erfolgreiches 2017 !!!
PL.

[udg]

@PureLust

wow danke für Dein Feedback. Leider ist es schon zu spät um auf alles jetzt einzugehen.
Ich habe den Neuesten Code in Post 1 ersetzt. Es wäre nett, wenn Du den noch mal analysieren würdest. Der gute Bisonte hat mich tatkräftig unterstützt.

Das das Programm gerade arbeitet, ja ist so ein Problem. Ich bin mir nicht wirklich sicher wie ich das am besten visuell darstelle. Bin am Überlegen so eine Animation reinzubauen wie man sie von den Android Apps kennt wenn sie laden. Im Moment keine Ahnung was das Beste ist. Der Anwender sollte auf jeden Fall sehen, das hier noch was arbeitet.

Inzwischen habe ich das Tool noch erweitert mit einem zweiten Checkbox Block. Hier soll man auswählen können, das man mit dem Tool nur nach speziefischen Endungen sucht (zb. MP3) und nur alle MP3 dateien dann in die TxT datei geschrieben werden.

Im Moment hänge ich aber an der Prozedur fest.

Hier mal ein Screen.



Hilfe bräuchte ich bei:
- Buttonproblem --> erledigt
- Anzeige, das das Programm noch arbeitet während des scannens und TxT schreiben --> erledigt
- evtl Geschwindigkeit? (Code ist angepasst) --> erledigt
- Hilfe beim unteren Checkbox Block --> erledigt

VG

[Micha122]

Hi udg

Mankos während das Programm arbeitet:

- Der Exit- Button ist "tot", keine Reaktion. Eigentlich die gesamte GUI. Werden ja keine Ereignisse mehr ausgewertet.
- Das Fenster lässt sich nicht verschieben oder minimieren. Es blockiert permanent den Desktop.
- Fenster friert ein wenn WriteDirText(File.s, List Files.s()) etwas länger dauert.

Was genau spricht gegen einen Thread??

Grüße

[udg]

Hi udg

Mankos während das Programm arbeitet:

- Der Exit- Button ist "tot", keine Reaktion. Eigentlich die gesamte GUI. Werden ja keine Ereignisse mehr ausgewertet.
- Das Fenster lässt sich nicht verschieben oder minimieren. Es blockiert permanent den Desktop.
- Fenster friert ein wenn WriteDirText(File.s, List Files.s()) etwas länger dauert.

Was genau spricht gegen einen Thread??

Grüße

Hi,
habe es gerade getestet. Ich persönlich hab noch keine Tests gemacht, ein komplettes Laufwerk einzulesen. Immer nur mit Ordnern. Beim Einlesen von einem Laufwerk hat es etwas länger gedauert, sodass genau das auftritt was Du beschreibst. So sollte es nicht sein.

Auf der anderen Seite: die erstellte TXT Datei war 8mb groß. Klingt nicht viel aber Windows hat Mühe die zu öffnen und darzustellen, geschweige denn dass man vernünftig scrollen kann aber wenn schon denn schon.

[Micha122]

Klingt nicht viel aber Windows hat Mühe die zu öffnen und darzustellen, geschweige denn dass man vernünftig scrollen kann aber wenn schon denn schon.

Nicht Windows hat da ein Problem mit sondern Dein Editor.

Mein Texteditor zeigt solch große Textdateien auf einem schwachem Netbook in gefühlt weniger als eine Sekunde an.


Edit:
Selbst der PB-Editor liest eine 10 MB große Textdatei in ca. einer Sekunde. Hätte ich nicht gedacht........Lob ans PB- Team!