WideStrings und GetDir$

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

  • Da Stringliterale und Stringvariablen seit einiger
    Zeit von XProfan automatisch per Referenz übergeben
    werden, sollte das der Einheitlichkeit wegen, für Widestrings
    auch sein. Folgendes geht z.Zt. nur per Addr() :

    Code
    $H Windows.ph
     Declare WideString s1, s2
     s1 = "Hello"
     s2 = "Info"
     Cls
     ~MessageBoxW(%HWnd, Addr(s1), Addr(s2), 0)
     Waitkey
     End

    Wahrscheinlich hat Roland das bei den neuen Wide-Strings vergessen.

  • Es müsste aber schon seit längerer Zeit bekannt sein, dass es GetDir$("@") heißt


    Bei mir sieht das schon immer so aus.

    Code
    VAR pfad$ = GetDir$("@")
    print pfad$
    waitinput
    end
  • Ja, hatte Roland schon im Profan-Forum gesagt.



    In der Hilfe waren alle @ entfernt worden

    Nicht ganz.
    Da stehen sie noch, bzw. werden sie gebraucht :



    @!(N) - @$(N) - @%(N) - @&(N)

    Am besten nimmt er bei GetDir$() den Leerstring "" .
    Wäre meiner Ansicht besser als der Klammeraffe.


    PS:
    Obwohl ich die Funktion von GetDir$() nicht so ganz verstehe.
    Da kann man sogar ungültige Laufwerksbuchstaben eingeben,
    ohne eine Fehlermeldung zu erhalten.
    Bei Angabe als "C:" habe ich das gleiche, wie $ProgDir.

  • Anregung :


    Ich würde mir das anders wünschen :


    DIR = ORDNER


    so bin ich es gewohnt.


    Also bei


    GetDir$("C:")


    - gibt alle Ordner vom Root C: in einem String durch | getrennt zurück


    z.B. "C:\\Programmme\\|C:\\ProgramData\\|C:\\Windows\\" usw.


    Wenn auch ein Unterordner mit angegben ist :


    GetDir$("C:\Windows")


    - gibt alle Unterordner in einem String durch | getrennt zurück.


    z.B. "C:\\WINDOWS\\Addins|C:\\Windows\\System\\|C:\\Windows\\System32\\" usw.


    Bei ungültigem Laufwerk/Ordner --> gibt einen Leerstring zurück.


    Das kann man dann auch schön mit Move("StrToList,...) weiter verarbeiten
    oder auch im String selber suchen.

  • GetDir$ taugt für 32Bit Windows Programme eigentlich nur für die Ermittlung der CurrentDirectory. Windows unterscheidet da eigentlich gar nicht zwischen Laufwerken.
    Die Funktionalität mal zu erweitern, wäre ein interessanter Ansatz - könnte aber ab Vista zum Haken der Anwendung führen, wenn zum Beispiel wirklich alle Unterverzeichnisse mit in den String aufgenommen würden, da in der Zeit, in der die Runtime sucht, keine Messages verarbeitet werden können.

  • Rekursive Datei- und Ordnersuchen würde ich generell sowieso ab XP nicht über XProfan Funktionen lösen, sondern per API. Neben einem Haken der Anwendung kann es ansonsten bei speziellen Programmen (oder bei speziellen Voraussetzungen im Betriebssystem :-D ) auch zu solchen Problemen kommen (je nachdem, wie XProfan die Suche implementiert): Rekursive Dateisuchen - wie sicher laufen eure?

  • Daß Roland das per API macht, setze ich eigentlich voraus.


    Er hat ja etliche Funktionen, die mit der API arbeiten. Diese
    werden von ihm ja nur als eigene Funktionen gekapselt und
    erweitert, damit der Anwender es etwas leichter hat und nicht
    erst in den Tiefen von MSDN wühlen muß.

  • Daß Roland das per API macht, setze ich eigentlich voraus.

    Es kommt auf das "wie" an und wonach man eigentlich sucht. ;-)


    Wenn Roland den verlinkten Artikel liest, sich einigermaßen mit Privilegien und mit Betriebssystemen ab Vista auskennt wird er wissen, worauf ich da hinaus will.


    Was einigermaßen sicher gehen würde, wäre das Listen der direkten Unterordner eines Ordners, wenn man einen Ordner übergibt. Übergibt man ein Laufwerk, müsste weiter die CurrentDirectory zurückgegeben werden.
    Kompatibel zum augenblicklichen Verhalten von GetDir$ wäre das aber nicht mehr.


    Wäre ich Roland, würde ich da gar nichts ändern und eventuell ein AddFolders zusätzlich einbauen. Wie das implementiert wird, würde ich mir aber sehr gut überlegen - gerade in Bezug auf neue Betriebssysteme. AddFiles würde ich eventuell kompatible anpassen und ebenfalls überarbeiten. Beides würde ich mir aber vorher, wie gesagt, sehr gut überlegen.

  • Er hat ja etliche Funktionen, die mit der API arbeiten.

    FindFirst$ ist meiner Meinung nach föllig ausreichend. Die Gefahr, das die Anwendung hakt, kann man damit komplett umgehen. Die Ordner kann man mittels DirExists herausfiltern und weitere Fehler (siehe verlinkter Beitrag) kann man mittels GetFAttr ausschließen. Eine solche Suche wäre zur Not sogar noch mittendrin abbrechbar.



    GetDir$ würde ich für so etwas nicht komplett umstricken. Hat da jemand einen Backslash zuviel in seinem Code, haut seine ganze Anwendung mit einer so umgestrickten XProfan Version nicht mehr hin. Das es sowieso unter Windows unsinnig ist GetDir$ anders zu nutzen als mit GetDir$("@"), lassen wir jetzt mal beiseite.
    AddFolders wäre da logischer - wenn überhaupt. Selbst AddFiles würde ich persönlich nicht nutzen.

  • Im Grunde hast du Recht.
    GetDir$() hatte ich bisher nie benutzt, da es ja genug
    Systemvariablen ($ProgDir usw. ) gibt.
    AddFiles ist auch nicht so mein Fall.
    Wenn man da gerade was anderes wichtiges in der Listboxliste
    hat und vergißt, den Inhalt irgendwo zwischenzuspeichern,
    hat man den Salat. Womöglich fällt es dann erst beim Endkunden
    auf.
    Da wäre mir eine Fuktion, die die Ordner in einem String mit |
    getrennt zurückgibt (oder auch ein Array), lieber. Zumal man
    mit den Move-Funktionen dann noch 'bewußt' in die Listboxliste
    hin - und herschieben kann.


    PS: Sind die verlinkten Ordner diejenigen, mit dem kleinen Pfeil drin ?
    Vielleicht kann man diese bereits bei der Suche erkennen und erst gar
    nicht im Suchergebnis aufnehmen. Da man auch mit dem Explorer
    nicht drauf zugreifen kann, sind die sowieso vorerst mal uninteressant.
    Da schreibt mit Sicherheit kein normaler Anwender was rein.

  • GetDir$() hatte ich bisher nie benutzt, da es ja genug
    Systemvariablen ($ProgDir usw. ) gibt.

    Die Systemvariablen zeigen aber nicht auf den aktuellen Ordner des Laufwerkes. Verrate mir mal, welche Systemvariable auf den aktuellen Pfad nach Programmstart zeigt ;-) Und einen hardcodierten Pfad hier anzusetzen geht auch nicht, also muß ich abfragen. Die Parameter zu GetDir$ sind allerdings nicht notwendig, es würde auch ein GetDir$() reichen. Ist nun aber mal so drin und würde nur Probleme aufwerfen, wenn da was dran geändert wird.


    Gruß Volkmar

  • Profan ist schon uralt. Damals war MS-DOS das Maß der Dinge und ein bißchen Kunterbunt drum, um die Bedienung zu vereinfachen. Nannte sich dann Windows 3 :-D . Und hier haben wir wohl so einen alten Zopf, der füher mal einfach ein DOS-Interrupt war. Geht heute so nicht mehr, die Befehlsyntax ist geblieben, um die Kompatibilität zu wahren.


    Gruß Volkmar

  • PS: Sind die verlinkten Ordner diejenigen, mit dem kleinen Pfeil drin ?

    Es handelt sich ab Vista um diese Ordner:


    Ist von meinem Vista System gezogen - auf anderen Betriebssystemen dürfte das in etwa gleich aussehen.

  • Verrate mir mal, welche Systemvariable auf den aktuellen Pfad nach Programmstart zeigt

    Was meinst du jetzt damit ?


    Spontan würde ich sagen : $ProgDir, also dort
    wo das aktuell laufende Profanprogramm gestartet
    wurde.


    Die Systemvariablen sind doch beim Programmstart
    mit Laufwerksnummer + Pfad vorbelegt, was ja auch Sinn
    und Zweck ist.


    Also ich habe bisher noch nicht mehr gebraucht, wenn ich
    im Programmlauf Daten oder Dateien in einen Ordner
    ablege oder sogar einen neuen erstelle.


    Für die allermeisten Anwendungsfälle müßte das doch genügen.


    Ich glaube, wir reden da aneinander vorbei.

  • Spontan würde ich sagen : $ProgDir, also dort
    wo das aktuell laufende Profanprogramm gestartet
    wurde.

    Nein. $ProgDir gibt den Pfad zurück, in dem das Programm abgelegt ist.
    Was mit GetDir$("@") ausgelesen wird, kann mit CHDIR geändert werden und entspricht dem, was die API GetCurrentDirectory zurückgibt.


    Da schreibt mit Sicherheit kein normaler Anwender was rein.

    Das in C:\Programme kein normaler Anwender irgendetwas hineinschreiben möchte, halte ich für ein Gerücht.

  • $ProgDir zeigt auf den Ordner, aus dem die EXE gestartet wurde. Stimmt also zum Beispiel nicht bei einer PRF- oder PRC-Datei. Und spätestens, wenn ich ChDir nutze, kommt alles ganz anders. Genau so gut kann ich auch ein Programm durch einen anderen Prozess starten, dann ist ist dessen aktueller Ordner jetzt mein aktueller Ordner, $ProgDir zeigt aber immer noch den Standort der EXE an. Oder in den Dateieigenschaften wird ein anderer ordner zum aktuellen Ordner erklärt "(Ausführen in" heißt das zum Beispiel bei Windows 7), bevor das Programm gestartet wird.


    Gruß Volkmar


    AHT war schneller :-)