Deutsch
DLLs

Addfiles.Dll: Datei- und Verzeichnisnamen rekursiv +Features

 
- Seite 1 -


Addfiles.Dll

Datei- und Verzeichnisnamen rekursiv + Features.

<!---->

Download/ In den Warenkorb
1,50 €
inkl. MwSt.
keine Versandgebühr

declare h&
cls
h&=createlistbox(%hwnd,"",10,10,400,200)
chdir "C:\lol"
external("addfiles.dll","AddFiles","*.*",h&,1)
external("addfiles.dll","AddDirs","*.*",h&,1)
external("addfiles.dll","AddFilesEx","*.*",h&,1)

while 1

    waitinput

wend


AddFiles(Maske$,ListboxHandle&,Recursion%)
AddDirs(Maske$,ListboxHandle&,Recursion%)
AddFilesEx(Maske$,ListboxHandle&,Recursion%)// liefert Dateiname*Größe*Zeit
SetProc(procAddr(myProc,1))
SetMsg(msgID)

Ebenso kann man mit SetProc(procAddr(myProc,1)) eine XProfan-Funktion für die Enumeration einsetzen, und optional per SetMsg(0) auf Messages verzichten:

Damit kann das Programm z.B. Anzeigen tätigen während gesucht wird - wichtig wenns mal länger dauert.

14 kB1,50 €
inkl. MwSt.
keine Versandgebühr
Artikel:DE-1404
Bezeichnung:Addfiles.Dll
Version:1.5
Kurzbeschreibung: Addfiles mit tollen Erweiterungen.
Hochgeladen:05.02.2009
Herunterladen
16 kB
Hochgeladen:23.12.2015
Ladeanzahl280
Herunterladen
 
12.09.2006  
 



 
- Seite 2 -


Der DLL sind von Seiten der Rekursion und Datei/Verzeichnisanzahl jedenfalls keine Grenzen gesetzt.

Die DLL nutzt die FindFirst-Api und legt die Ergebnisse in die per Handle angegebene Listbox. Listboxen sind imho in der Anzahl der Einträge beschränkt. Hier könnte man ein Dummyhandle angeben welches die ListBox-Message abfängt und tatsächlich die Daten anders speichert - so könntest Du tun... oder die ListBox einfach subClassen um abzufangen.
 
01.10.2008  
 




Frank
Abbing

Listboxen sind imho in der Anzahl der Einträge beschränkt.


Unter WinXP nicht, soweit ich aus eigener Erfahrung sprechen kann. Jedenfalls soweit der Speicher reicht.
 
04.10.2008  
 




Stefan
M.
Caillet
Hallo iF,
Hab da immer noch ein kleines Problem mit Deiner Addfiles.dll (oder der ListBox, die die Ordner aufnimmt?)!
Folgender Code läuft problemlos wenn ich ihn über das LW E: (ist meine 2. - die Daten-Partition meines Laptops) schicke. Mach ich das mit LW C: , wird die 1.LBox anscheinend gefüllt, der Inhalt aber nicht angezeigt, sonden die LBox irgendwann einfach entfernt, und einigezeit später das PROG einfach geschlossen. Was dabei seltsam ist, ist die Tatsache, dass das Prog. auf meinem PC korrekt läuft. Ich empfinde es jedoch als sehr Wichtig, dass das Prog. auch auf meinem LapTop perfekt läuft. Da das Problem währen ADDDIR auftritt, hoffe ich, dass Du den Fehler finden kannst. Die Anzahl der Ordner sollte eigentlich nicht das Problem sein, denn auf dem PC findet werden auf LX C: über 3300 ORDNER gefunden - Auf dem LapTop sollten es eigentlich weniger sein. Getestet unter Win XP , XPROFAN 10.0a + 11.1
KompilierenMarkierenSeparieren
Suche bestimmten Ordner auf allen vohandenen und bereiten Laufwerken
Def GetLogicalDrives(0) ! KERNEL32, GetLogicalDrives
Def GetDriveType(1) ! KERNEL32, GetDriveTypeA
Def GetVolumeInformation(8) !KERNEL32,GetVolumeInformationA
Def SetErrorMode(1) !KERNEL32,SetErrorMode
Def ext.addfiles(3) !addfiles.dll, AddFiles
DEF ext.addfilesex(3) !addfiles.dll, AddFilesEx
Def ext.adddirs(3) !addfiles.dll, AddDirs
declare drives&, lw$,Drives$[31],N%,DRV$
declare H&,H0&,H1&,H2&,I%,j%,font&,dll&,mode&,SUCHORDNER$,SUCHFILE$
declare buffer#, dirbuf#, H$
dim buffer#, 4
font&=Create(Font,tahoma,14,0,1,0,0)
dll&=usedll(addfiles.dll)

Proc CheckDrive  Test auf Laufwerk bereit (Disk, CD/DVD eingelegt ?)

    Parameters drive$
    Declare result&,olderrormode&,dw1&,dw2&
    Let olderrormode&=SetErrorMode(1)
    Let drive$=Upper$(Mid$(drive$,1,1))+:
    Dim dirbuf#,Len(drive$)+2
    String dirbuf#,0=drive$
    Let result&=GetVolumeInformation(dirbuf#,0,0,0,Addr(dw1&),Addr(dw2&),0,0)
    SetErrorMode(olderrormode&)
    Dispose dirbuf#
    Return result&

EndProc

Proc ReadyDrives$

    Declare DRV$
    drives& = GetLogicalDrives()

    whileloop 0, 31

        Prüfen ob Laufsbuchstabe vergeben

        if TestBit(drives&, &loop)

            lw$ = Chr$(&loop + 65) + :
            string buffer#, 0 = lw$
            Drives$[n%] = LW$ : Inc N%

        endif

    endwhile

    dispose buffer#
    Dec N%
    DRV$ =

    WhileLoop 0, N%

        Case CheckDrive(Drives$[&loop])=1 : DRV$ = DRV$ + Drives$[&loop] + |

    EndWhile

    N% = len(DRV$)/4
    DRV$=DRV$+Right$(0+STR$(N%),2)
    Return DRV$

EndProc

cls
H& = Create(ListBox,%HWND,1,10,20,200,150)
H0& = Create(ListBox,%HWND,1,216,20,200,150)
H1& = Create(ListBox,%HWND,1,422,20,200,150)
H2& = Create(ListBox,%HWND,1,10,190,612,200) : SetFont H2&,Font&
DRV$=ReadyDrives$()
SuchOrdner$=DESITRONBKPFILES
SuchOrdner$=Upper$(SuchOrdner$)
SuchFile$=SMC_adress.bkp
Suchfile$=Upper$(Suchfile$)

WhileLoop 1,1  1. Laufwerk C: (A: ohne Disk, B: nicht vorhanden)   Val(Right$(DRV$,2))

    Clearlist H& : Clearlist H0& : Clearlist H1&
    print Druchsuche Laufwerk +SubStr$(DRV$,&loop,|);
    ChDir SubStr$(DRV$,&loop,|)+
    ext.adddirs(*.*,H&,1)
    N% = Getcount(H&)
    print   - > +STR$(N%)+ Ordner vorhanden, wovon ;
    waitinput  Nur zum Test, um zu sehen, ob erste LBOX korr. gefüllt wird!
    N% = 0

    WhileLoop GetCount(H&)

        If INSTR(SUCHORDNER$,UPPER$(GetString$(H&,N%)))

            CaseNot INSTR(SUCHORDNER$+,UPPER$(GetString$(H&,N%))): Addstring(H0&,GetString$(H&,N%))

        EndIf

        inc N%

    EndWhile

    N% = Getcount(H0&)
    Print Str$(N%)+ +SuchOrdner$

    If GetCount(H0&)

        N% = 0

        WhileLoop GetCount(H0&)

            ChDir GetString$(H0&,N%)
            ext.addfiles(*.*,H1&,1)
            inc N%

        Endwhile

    Endif

    Print Dieser enthält +Str$(GetCount(H1&))+Dateien ;

    If GetCount(H1&)

        N% = 0

        WhileLoop GetCount(H1&)

            Case InStr(SuchFile$,Upper$(GetString$(H1&,N%))) : AddString(H2&,GetString$(H1&,N%))
            INC N%

        EndWhile

        Print wovon +STR$(GetCount(H2&))+ +Suchfile$

    EndIf

    print

EndWhile

If GetCount(H2&)

    H$=GetString$(H2&,0)
    Print SubStr$(H$,-1,)

endif

Print fertig
WAITINPUT
deleteobject Font&

Danke.
Gruss Stefan
 
Ich habe grosses Glück, weil ich Mitmenschen helfen darf.
Entwicklungsumgebung:
XProfan11 , Win XP Pro 32Bit , Win XP Home ,Win7 HomePremium 64Bit
PC: P4/3GHz , 2GB RAM , 1700GB HD
Laptop: Intel Core 2 Duo /2,2GHz , 4GB RAM , 500GB HD
06.01.2009  
 



Teste mal bitte, wenn die ListBox mit create(list,...) erzeugt wurde, ob das Problem dann noch auftritt.

Der DLL sind im Grunde die Anzahl von Dateien und Ordnern sowie die Rekursion völlig egal.
 
06.01.2009  
 




Stefan
M.
Caillet
Hallo iF,
hilft leider auch nicht.
Festgestellt hab ich noch Folgendes: Während der Suche beträgt die maximale Prozessorlast zwischen 25% und 52% - was ich als OK erachte. der Speicherbedarf steigt bis zum Zeitpunkt wo das Fenster geschlossen wird auf 126510 KB, also knapp 126 MB! Auf dem PC liegt der Speicherbedarf bei max. 20123 Kb also knapp 20 MB! Diese 126MB finde ich etwas hoch? Was meinst Du?
Danke.
Gruss Stefan
 
Ich habe grosses Glück, weil ich Mitmenschen helfen darf.
Entwicklungsumgebung:
XProfan11 , Win XP Pro 32Bit , Win XP Home ,Win7 HomePremium 64Bit
PC: P4/3GHz , 2GB RAM , 1700GB HD
Laptop: Intel Core 2 Duo /2,2GHz , 4GB RAM , 500GB HD
06.01.2009  
 



Hab noch kein Plan, ich könnte frühstens morgen eine Debug-Version posten wenn Du diese dann einmal testen möchtest.

Die DLL sendet Message 384 = LB_ADDSTRING an das übergebene Handle mit Adresse für den Speicher des Stringinhaltes im lParam.

Du könntest auch testen und ein Static erzeugen und subclassen auf Message 384 (LB_ADDSTRING) - den ankommenden lParam z.B. per wm_setText an hWnd weiterleiten und im Titel vom hWnd sehen, welcher Eintrag da möglicherweise Probleme macht.
 
06.01.2009  
 




Stefan
M.
Caillet
Hallo iF,
Danke für Deine Mühe. Ja, selbstverständlich möchte ich gerne durch Tests mithelfen den Fehler zu lokalisieren. Nur fürchte ich, dass ich selbst dazu Deine Hilfe in Form der dazu benötigten SubclassProc für das Static. Ich hab das mit dem Subclassing leider einfach noch nicht drauf. Kannst Du mir bitte die benötigte Erweiterung/Änderung an meinem Code zeigen. Ich weiss zwar durch Deine Hilfe im vorigen Posting, was Du meinst, kann es aber mangels Sattelfestigkeit im Subclassing , nicht in funktionirenden Code umsetzen.
Währe Dir sehr für Deine Hilfe dankbar.
Danke.
Gruss Stefan
 
Ich habe grosses Glück, weil ich Mitmenschen helfen darf.
Entwicklungsumgebung:
XProfan11 , Win XP Pro 32Bit , Win XP Home ,Win7 HomePremium 64Bit
PC: P4/3GHz , 2GB RAM , 1700GB HD
Laptop: Intel Core 2 Duo /2,2GHz , 4GB RAM , 500GB HD
06.01.2009  
 



Du kennst das... Du würdest gerne... aber hast ca. 500 Fenster offen die auf Eingaben warten...

Ich schau gleich mal...
 
06.01.2009  
 




Stefan
M.
Caillet
Also, iF, Ich habe nochmals etwas getestet und experimentiert. Hab auch versucht, das mit dem Subclassing zum laufen zu kriegen, allerdings ohne erfolg - es war mir nicht möglich, eine Message von Deiner dll abzufangen - scheint an meiner Unfähigkeit in der Subclassprogrammierung zu liegen. Jedoch war es mir moglich, LW C: auf dem LapTop mit dem XProfan-Befehl Addfiles *.* zu durhsuchen. Da aber Addfiles das bekannte Problem mit dem Staküberlauf hat, (unter XProfan 11.1 immernoch?? - steht jedenfalls noch so in der Hilfe zu XProfan11), möchte ich lieber auf Deine dll zurückgreifen. Ein weiter Vorteil Deiner dll ist natürlich das AddDir - was ich hier nämlich eigentlich brauche, da ich eigentlich erstmal den ORDNER BKPFILES suchen muss - jedoch auf sämtlichen vorhandenen und lesebereiten Laufwerken.
Hast Du schon ne Idee (nen Code) mit dem ich das mit dem Subclassing testen kann, um herauszufinden, wo es hakt?
Danke.
Gruss Stefan
 
Ich habe grosses Glück, weil ich Mitmenschen helfen darf.
Entwicklungsumgebung:
XProfan11 , Win XP Pro 32Bit , Win XP Home ,Win7 HomePremium 64Bit
PC: P4/3GHz , 2GB RAM , 1700GB HD
Laptop: Intel Core 2 Duo /2,2GHz , 4GB RAM , 500GB HD
07.01.2009  
 



@Stefan
aus dem Updatetext von XPatch111.Zip


AddFiles *. gewaltig beschleunigt und funktioniert jetzt auch für große Festplatten
ohne Stacküberlauf
 
07.01.2009  
 




Stefan
M.
Caillet
@Horst, ja jetzt wo Du es sagst, kann mich dunkel dran erinnern, mal sowas gelesen zu haben.
Im Vorteil ist, wer sich das gelesene auch merken kann.
Danke.
Gruss Stefan
 
Ich habe grosses Glück, weil ich Mitmenschen helfen darf.
Entwicklungsumgebung:
XProfan11 , Win XP Pro 32Bit , Win XP Home ,Win7 HomePremium 64Bit
PC: P4/3GHz , 2GB RAM , 1700GB HD
Laptop: Intel Core 2 Duo /2,2GHz , 4GB RAM , 500GB HD
07.01.2009  
 




Michael
Wodrich
FindFirst - FindNext - FindClose
Da gab es ein Speicherleck-Problem, wenn man nicht gut aufpaßt.
Außerdem: Wenn FindFirst keine Dateien in einem Verzeichnis findet, dann darf auf keinen Fall ein FindClose folgen.

Zum Laptop:

Ich hatte einen Vista-Laptop zum Testen. Einige Programme liefen nicht so wie auf meinem Heimrechner. Der Grund waren versteckte Systemverzeichnisse von Microsoft in einem Fall und ein komprimiertes Verzeichnis in einem anderen Fall.

Die Verzeichnis-Namen weiß ich jetzt nicht mehr, es waren aber 2 die mit Recycling zu tun hatten und eines für die Systemwiederherstellung.

Vielleicht helfen diese Infos ja weiter.

Schöne Grüße
Michael Wodrich
 
Programmieren, das spannendste Detektivspiel der Welt.
07.01.2009  
 




Zur DLL


Thementitel, max. 100 Zeichen.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Beitrag  Schrift  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Themenoptionen

93.635 Betrachtungen

Unbenanntvor 0 min.
H.Brill vor 24 Tagen
R.Schneider31.08.2024
Erhard Wirth14.06.2024
Member 862464103.06.2024
Mehr...

Themeninformationen



Admins  |  AGB  |  Anwendungen  |  Autoren  |  Chat  |  Datenschutz  |  Download  |  Eingangshalle  |  Hilfe  |  Händlerportal  |  Impressum  |  Mart  |  Schnittstellen  |  SDK  |  Services  |  Spiele  |  Suche  |  Support

Ein Projekt aller XProfaner, die es gibt!


Mein XProfan
Private Nachrichten
Eigenes Ablageforum
Themen-Merkliste
Eigene Beiträge
Eigene Themen
Zwischenablage
Abmelden
 Deutsch English Français Español Italia
Übersetzungen

Datenschutz


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie