Sammelthread "AutoIt Interne Funktionen : Erwartetes Ergebnis -> Tatsächliches Ergebnis"

  • In diesem Thread geht es um Funktionen,

    - deren Verhalten von der in der Hilfe beschriebenen Weise abweichen

    - deren Übergabeparameter/Rückgabewerte Inkonsistenzen zeigen

    - die sonstige, unerwartete Besonderheiten aufweisen


    Zusätzlich zu den internen AutoIt-Funktionen kann auch auf vergleichbare Probleme und/oder Lösungsvorschläge in UDF's eingegangen werden, die von der Community erstellt wurden. Dabei sollten wir uns aber auf UDF's beschränken, die 'qualitativ allgemein anerkannt' sind.

    Falls die Besonderheit bereits in einem eigenen Thread behandelt/gelöst wurde, dann langt als Antwort ein entsprechender Link, z.B : Merkwürdiges Verhalten bei DirMove


    Der Thread ist als Ergänzung zur AutoIt-Hilfe gedacht, soll diese aber keinesfalls ersetzen !


    Durch die Themenbreite wird das ganze zwangsläufig unübersichtlich bzw. unstrukturiert. Schwer vorherzusehen, ob ein Thread in dieser Form überhaupt funktioniert:/. Ich bitte daher, von 'Leerbeiträgen' wie "... finde ich auch ..." usw. abzusehen.


    Kommentare, Fragen und Sonstiges können im Allgemeinen Diskussionsthread gepostet werden !


    Um die Pflege der Funktionsübersicht zu erleichtern, muss folgendes an den Anfang des jeweiligen Beitrages gestellt werden :

    - Name der betreffenden Funktion (UDF)

    - ggf. eine beschreibende Kurzinformation

    Zusätzlich ist es hilfreich, wenn der Beitragsersteller folgende Angaben macht :

    - die verwendete Version des Betriebssystems (z.B. 'Win7 x64') und AutoIt (z.B. Au3: 3.3.14.5)

    - wurde das Skript für 32-Bit bzw. 64-Bit 'kompiliert (#AutoIt3Wrapper_UseX64 = N bzw Y)


    Funktionsübersicht :

    1. Auflistung der bisherigen Shoutbox-Beiträge zu : GUITreeView

    Kurzinfo : siehe Startbeitrag weiter unten

    2. WinGetHandle (Link)

    Kurzinfo : WinGetHandle('[CLASS / WinGetHandle('[REGEXPCLASS

    3. ControlSend / ControlGetText (Link)

    4. TreeView-Bug / "-1"-Bug (Win7 x64 - Au3: 3.3.14.5) (Link)

    5. TreeView DeleteChildren-Bug/Inkonsistenz (Win7 x64 - Au3: 3.3.14.5) (Link)

    6. Funktion DirMove (Link)

    Kurzinfo :

    Falls das Zielverzeichnis bereits existiert wird ein weiteres Unterverzeichnis angelegt - die Daten werden nicht in das bestehende Verzeichnis integriert

    7. Funktion DirCopy (Link)

    Kurzinfo : DirCopy mit Flag $FC_NOOVERWRITE bricht ab, auch wenn das Zielverzeichnis leer ist

    8. Funktion Opt('MustDeclareVars', 1) (Link)

    Kurzinfo: AU3Check schlägt nicht immer Alarm bei Opt('MustDeclareVars', 1)

    9. Subtrahieren von Fließkommazahlen (Link)

    Kurzinfo :

    Subtrahieren von Fließkommazahlen (floating point numbers) - auch Gleitkommazahlen genannt :

    Ändern der Reihenfolge liefert unterschiedliche Ergebnisse !

    10. Funktion Round -> Rückgabe unterschiedlicher Datentypen (Link)

    Kurzinfo :

    Dieses Verhalten tritt auf, wenn man den optionalen Parameter decimalplaces, also die Anzahl der gewünschten Nachkommastellen (selbst bei 0), verwendet oder weglässt.

    11. Funktion WinGetPos und GUISetState(@SW_MINIMIZE) (Link)

    Kurzinfo :

    WinGetPos liefert nicht wie erwartet die Position und Größe des minimierten Fensters, wenn direkt nach GUICreate('') ein GUISetState(@SW_MINIMIZE) ausgeführt wird

    Anmerkung :

    Bitnugger hat seinen Beitrag freundlicherweise erweitert, um eventuelle Missverständnisse zu vermeiden.

    12. Der Au3Stripper 'parst' einige ternäre Ausdrücke nicht korrekt (Link)

    Kurzinfo : Vom Au3Stripper erzeugter Code (*_stripped.au3) ist bei gewissen Notationen fehlerhaft.

    -> Offiziell gefixt in SciTE4AutoIt > 4.1.2 (alles nach dem 02-01-2019)

    13. Vorsicht bei den Hilfebeispielen zu einigen _WinAPI_Path... Funktionen (Link)

    Kurzinfo :

    Die Hilfebeispiele zu _WinAPI_PathRemoveArgs, _WinAPI_PathGetArgs und _WinAPI_PathParseIconLocation verwenden die Funktion _WinAPI_AssocQueryString.

    Diese Funktion ermittelt ungünstigerweise Werte aus der Registry, welche mal mit und mal ohne Anführungsstriche angegeben werden. Somit kann es zu einem Rückgabewert kommen, der in den _WinAPI_Path... Funktionen nicht verwertbar ist.



    (... hier werden neue Punkte eingefügt)


    Anmerkung : Warum starte gerade ich diesen Thread ?

    In den letzten Tagen gab es in der Shoutbox mal wieder eine interessante Diskussion (siehe Auflistung) mit sehr nützlichen Erkenntnissen. Da die Shoutbox aber nur für Mitglieder sichtbar ist, gehen Gästen diese Informationen verloren. Zudem verschwinden Shoutbox-Beiträge recht schnell im Archiv und werden dann auch von Mitgliedern nicht mehr gefunden.

    Da ich die Bitte geäußert habe daraus einen Thread zu machen, wurde mir prompt diese Ehre zuteil - meinen Dank an Bitnugger  :P


    Nachfolgend die Auflistung der bisherigen Shoutbox-Beiträge zu : GUITreeView


    alpines Freitag, 25.01.2019

    Wow, darauf muss man erstmal kommen. Wenn man _ArrayDisplay verwendet, darf man nicht mit GUITreeView* neue Items erstellen und mit -1 draufzugreifen (obwohl die Parentcontrols etc. richtig übergeben werden!!!), denn es ist ja noch die ArrayDisplay GUI "aktiv" obwohl diese geschlossen wurde.

    Also entweder GUISwitch vor dem Erstellen der TreeViewItems, oder man speichert das Handle ab und übergibt es. Dann klappt es, egal auf welcher GUI man ist.

    Man hätte auch ruhig die aktuelle GUI (inkl. Tabitem falls vorhanden) auslesen können und im Nachhinein wieder mit GUISwitch setzen können.


    Anm. Bitnugger : Ja, total ätzend... oder einen zusätzlichen Parameter $hWnd, wie bei MsgBox.


    Bitnugger Samstag, 26.01.2019

    Eigentlich ist es aber ein Fehler von GUISwitch... das mit dem Handle der nicht mehr existierenden GUI von _ArrayDisplay/_DebugArrayDisplay hantiert, anstatt das zuvor gültige

    GUI zu verwenden, falls vorhanden.


    alpines Samstag, 26.01.2019

    Nein, mit GUISwitch funktioniert es ja. Das -1 greift auf die falsche GUI zu, übergebe ich allerdings das Handle von dem Item (OHNE GUISwitch) klappt es, mit -1 nicht.


    Bitnugger Sonntag, 27.01.2019

    Das -1 greift auf eine nicht mehr existierende die falsche GUI zu" ... ...AutoIt sollte das erkennen und die zuletzt gültige GUI anstelle der nicht mehr existierenden GUI verwenden.


    alpines Sonntag, 27.01.2019

    Genau, mit GUISwitch hat das ja aber nichts zu tun. Das behebt ja den Fehler, ohne klappts nur mit Handle.


    Bitnugger Sonntag, 27.01.2019

    Stimmt... ideal wäre also, wenn AutoIt beim Löschen einer GUI den Fokus automatisch auf eine zuvor erstellte und noch existierende GUI setzt, oder das Control nicht erstellt, falls keine existiert.


    Bitnugger Montag, 28.01.2019

    GUICtrlGetState($g_idIOListView) <-- hat mir heute den Tag versaut... weil --> "For ListView controls it returns the number of the clicked column."


    alpines Montag, 28.01.2019

    Ja, das hatte ich auch vor ein paar Monaten lernen müssen. Sowas wird aber leider niemals gefixt werden. Auch schön zu "erfahren", dass einige TreeView-Funktionen mit @GUI_CtrlId funktionieren, und einige auf GUICtrlGetHandle(@GUI_CtrlId) angewiesen sind.


    BugFix Dienstag, 29.01.2019

    Wenn du willst, dass es wirklich funktioniert: Eigenes Handling aller Messages durchführen.

    Dann weißt du wenigstens, dass du selbst der Depp warst, wenn es nicht klappt.

    86598-musashi-c64-png

    25 Mal editiert, zuletzt von Musashi () aus folgendem Grund: Übersicht erweitert

  • Zu : ControlSend / ControlGetText

    Bitnugger Mittwoch, 30.01.2019

    Und hier noch so ein Ding für die Sammlung... ControlSend($hCtrl, '', '', 'BlaBlaBla') funktioniert... aber ControlGetText($hCtrl , '', '') funktioniert nicht... !


    alpines Mittwoch, 30.01.2019

    Das mit dem ControlSend/GetText würde ich aber nicht notwendigerweise so einstufen.

    Der 1. Parameter soll title/hWnd/class von dem Fenster sein, und controlId das was du übergibst.

    Strenggenommen sind ja Controls auch hWnds aber ich denke du verstehst was ich meine.

    In die Sammlung sollten eher Sachen die nicht so funktionieren wie sie sollten.

  • Tolle Aktion :thumbsup:


    Damit das jeder nachvollziehen kann hier der Code zum TreeView-Bug / "-1"-Bug (Win7 x64 - Au3: 3.3.14.5)


    Es wird eine $hMainGUI erstellt die angezeigt wird. Diese dient als Haupt-GUI und öffnet die TreeView GUI und nachdem die TV-GUI angezeigt wird, @SW_DISABLEn wir die Haupt-GUI.

    Nun können wir wahllos Items anklicken und neue Unteritems spawnen lassen und es taucht eine neue GUI von _ArrayDisplay auf.


    Diese schließen wir und versuchen neue Items zu spawnen, dies ist allerdings nur auf den Items möglich die schon existierten.

    Spawnen wir ein Neues Item und versuchen mit dem Klick auf das Neue Item "Neu" wieder ein neues zu spawnen schlägt das fehl,

    denn das Event wurde nicht gesetzt. Da im GUICtrlCreateTreeViewItem kein -1 auftaucht sondern mit der Variable gearbeitet wird wird das Item zumindest erstellt.


    Der Bug ist also der, dass das Setzen von Events (oder andern Sachen die mit -1 funktionieren) auf Controls nicht funktionieren, die korrekt erstellt wurden,

    während eine andere GUI "aktiv" war. Denn das -1 bezieht sich immer auf das letzte Control und inklusive auf die letzte "aktive" GUI. (Aktiv im Sinne von SetState benutzt und nicht unbedingt Controls darauf erstellt!)


    Und nicht wie es überall in der Hilfe steht nur auf das letzte Control.

    The control identifier (controlID) as returned by a GUICtrlCreate...() function, or -1 for the last created control.


    Der Grund dafür ist, dass das -1 im GUICtrlSetOnEvent auf das falsche Control der falschen GUI zeigt (sollte eigentlich immer auf das letzte Control zeigen).

    Verwenden wir aber nun statt dem -1 die Variable mit dem ID des Controls werden auch bei den neuen Items wieder neue erstellt obwohl die GUI von ArrayDisplay auftauchte.

    Mit dem -1 klappt es nur wenn wir GUISwitch verwenden.


    Btw: Das TreeView-Begin/EndUpdate ist nicht zwangsweise notwendig, allerdings erscheinen die [+] nicht sofort (visuell) wenn man es nicht drin hat.

  • Ich hoffe es stört nicht, dass ich doppelt poste, aber so kannst du einfacher zu den Themen verlinken die du in den ersten Beiden Beiträgen angeschnitten hattest.


    TreeView DeleteChildren-Bug/Inkonsistenz (Win7 x64 - Au3: 3.3.14.5)


    Hier wurde einfach schlecht programmiert.

    Einige _GUICtrlTreeView-Funktionen akzeptieren das Standard-AutoIt-TreeViewItem (welches man mit der ID anspricht) aber DeleteChildren sträubt sich da, der Grund ist auch "schnell" gefunden.

    Einige Funktionen rufen nämlich intern noch _GUICtrlTreeView_GetItemHandle auf und arbeiten mit dem hWnd des Controls weiter, allerdings passiert das bei _GUICtrlTreeView_DeleteChildren nicht.


    Übergibt man kein hWnd (also einfach nur die ID vom Standard-TreeView-Control), so wird der Else-Zweif in der Funktion ausgeführt und als $lParam von GUICtrlSendMsg wird die AutoIt-Interne-ID eines Items weitergegeben.

    Das selbe Problem sollte auch beim Nicht-Else Zweif auftreten, allerdings muss man dann GUICtrlGetHandle um das TreeView packen und das Item normal übergeben was niemand machen würde.

    Code
    1. Func _GUICtrlTreeView_DeleteChildren($hWnd, $hItem)
    2. Local $bResult
    3. If IsHWnd($hWnd) Then
    4. $bResult = _SendMessage($hWnd, $TVM_EXPAND, BitOR($TVE_COLLAPSE, $TVE_COLLAPSERESET), $hItem, 0, "wparam", "handle")
    5. Else
    6. $bResult = GUICtrlSendMsg($hWnd, $TVM_EXPAND, BitOR($TVE_COLLAPSE, $TVE_COLLAPSERESET), $hItem)
    7. EndIf
    8. Return $bResult
    9. EndFunc


    Allerdings erwartet $TVM_EXPAND als $lParam ein hWnd (einen Pointer!) und keine AutoIt-Interne-ID.

    AutoIt erkennt das nicht automatisch und so wird als lParam einfach die ID gesendet welches auf einen ungültigen Speicherplatz zeigt und folglich das Control nicht gelösht werden kann.


    Fix: GUICtrlGetHandle verwenden wenn man Items an _GUICtrlTreeView_DeleteChildren versendet, dann übergibt man nämlich einen Pointer.

    Oder man setzt vollständig auf die UDF und verwendet kein einziges Standardcontrol, dann bräuchte man ehrlich gesagt aber die Tausend Abfragen nicht die in der UDF enthalten sind (die die Standardcontrols akzeptierbar machen).


    Dass hier, $TVM_EXPAND zum löschen mit $TVE_COLLAPSERESET verwendet wird, will ich mal außen vor lassen, bei mir erzeugt das einen visuellen Bug.

    Das [+] vor dem "A" verschwindet nicht, obwohl das Item keine Unteritems mehr hat und man es auch nicht mehr expandieren kann.

  • Offiziell gefixt in 3.3.10.0:

  • Funktion : DirMove (Win7 x64 - Au3: 3.3.14.2)


    Beschreibung :

    Hat man z.B. ein Verzeichnis d:\Quelle und möchte dieses Verzeichnis mittels DirMove nach d:\Ziel verschieben (Flag $FC_OVERWRITE ist gesetzt), dann :

    -> d:\Quelle wird entfernt

    -> unter d:\Ziel wird das Verzeichnis \Quelle angelegt -> der komplette Pfad lautet : d:\Ziel\Quelle


    Wiederholt man den Vorgang, d.h. d:\Quelle wird erneut befüllt und verschoben, erwartet man :

    -> d:\Quelle wird entfernt

    -> in d:\Ziel\Quelle werden die Daten aktualisiert, d.h. existierende Daten werden überschrieben und neue Daten werden hinzugefügt


    Was aber passiert ist : Es wird ein (weiteres) neues Unterverzeichnis \Quelle hinzugefügt, also

    d:\Ziel\Quelle\Quelle [ad infinitum]


    Details und 'Workaround' siehe : Merkwürdiges Verhalten bei DirMove

  • Funktion : DirCopy (Win7 x64 - Au3: 3.3.14.2)


    Beschreibung :

    Selbst wenn man alle Dateien und (falls vorhanden Unterverzeichnisse) aus dem Zielverzeichnis entfernt, werden keine Dateien kopiert. Offensichtlich findet mit dem Flag $FC_NOOVERWRITE nur ein Test auf die Existenz des Zielverzeichnisses statt. Existiert es bereits, bricht DirCopy ab.


    Erst mit dem Flag $FC_OVERWRITE werden die fehlenden Dateien kopiert.


    Details siehe : Merkwürdiges Verhalten auch bei DirCopy

  • Funktion: Opt('MustDeclareVars', 1)

    Wenn im Script die Pre-Deklaration von Variablen mit Opt('MustDeclareVars', 1) erzwungen wird, bevor man sie benutzen darf, denkt und erwartet man, dass AU3Check meckert, wenn dann doch eine Variable benutzt wird, die vorher nicht deklariert wurde - und wenn AU3Check nicht meckert, dass alles im grünen Bereich ist und das Script dann keinesfalls an irgendeiner Stelle abbricht, weil es auf eine nicht deklarierte Variable stößt.


    Falsch gedacht...


    Hier ein Bsp:


    In den meisten Fällen wird das Script sofort beendet und eine entsprechende Fehlermeldung ausgegeben, wenn es bei der Ausführung dann doch auf eine nicht pre-deklarierte Variable stößt, aber dies ist nicht immer der Fall! In diesen speziellen Fällen - wenn keine Fehlermeldung kommt und das Script einfach nur einfriert - wird es meist sehr schwer, den Fehler zu finden.


    Hier der relevante Teil der Funktion, die mir graue Harre beschert hat...

  • Subtrahieren von Fließkommazahlen - Ändern der Reihenfolge liefert unterschiedliche Ergebnisse!


    Bei ganzen Zahlen spielt es keine Rolle, in welcher Reihenfolge die zu subtrahierenden Zahlen stehen, hier ein Bsp.:

    Code
    1. ConsoleWrite('+ 60 - 18 - 2 - 10 = ' & 60 - 18 - 2 - 10 & @CRLF) ; 30
    2. ConsoleWrite('+ 60 - 10 - 18 - 2 = ' & 60 - 10 - 18 - 2 & @CRLF) ; 30
    3. ConsoleWrite('+ 60 - 2 - 20 - 18 = ' & 60 - 2 - 20 - 18 & @CRLF) ; 30
    4. ConsoleWrite('+ 60 - 2 - 18 - 20 = ' & 60 - 2 - 18 - 20 & @CRLF) ; 30


    Bei Fließkomazahlen sieht es jedoch anders aus, hier ein Bsp.:

    Code
    1. ConsoleWrite('! 78.08 - 11.07 - 67.01 = ' & 78.08 - 11.07 - 67.01 & @CRLF) ; -1.4210854715202e-014 <--
    2. ConsoleWrite('! 78.08 - 67.01 - 11.07 = ' & 78.08 - 67.01 - 11.07 & @CRLF) ; -7.105427357601e-015 <--
    3. ; Mit Klammersetzung kann man dies verhindern.
    4. ConsoleWrite('- 78.08 - (11.07 + 67.01) = ' & 78.08 - (11.07 + 67.01) & @CRLF) ; -1.4210854715202e-014
    5. ConsoleWrite('- 78.08 - (67.01 + 11.07) = ' & 78.08 - (67.01 + 11.07) & @CRLF) ; -1.4210854715202e-014

    Zudem ist das Ergebnis in allen vier Fällen nicht 0, wie es beim Windows Calculator, meinen Taschenrechner und dem Rechner auf meinem Smartphone der Fall ist...


    Deshalb: Bei Berechnungen mit Gleitkommazahlen das Ergebnis niemals auf Gleichheit prüfen (beliebter Anfängerfehler), sondern stets eine Prüfung um ±Epsilon (einer beliebig kleinen Zahl größer als null) durchführen.

    Danke Xorianator


    Einigen Usern sind die Hintergründe sicher nicht bekannt, warum es bei der "Fließkomma-Arithmetik" zu "unerwarteten Ergebnissen" kommt, welche aber nicht als Bug (Fehler) einzustufen sind. Ausführliche Infos zu diesem Thema findet man z.B. hier:

    https://py-tutorial-de.readthe…latest/floatingpoint.html

    https://www.mikrocontroller.net/articles/Gleitkommazahlen

  • Wird Round() in Kombination mit Funktionen verwendet, die je nach Datentyp unterschiedlich agieren (z.B. Hex(5) <> Hex(5.0)), kann es zu unerwarteten Ergebnissen führen, da Round() als Rückgabetyp immer ein Double liefert, sofern der optionale Parameter "decimalplaces" mit angegeben wird - wird dieser weggelassen, ist der Rückgabetyp immer Int32.

    Code
    1. ConsoleWrite('+ --------------------------------------------------------------------------------------------------------- ' & @CRLF)
    2. ConsoleWrite('+ Die Verwendung des optionalen Parameters "decimalplaces" führt zur Rückgabe unterschiedlicher Datentypen : ' & @CRLF)
    3. ConsoleWrite('! Datentyp ohne "decimalplaces" -> Round(5.5) = ' & VarGetType(Round(5.5)) & @CRLF)
    4. ConsoleWrite('! Datentyp mit "decimalplaces" -> Round(5.5, 0) = ' & VarGetType(Round(5.5, 0)) & @CRLF)
    5. ConsoleWrite('+ --------------------------------------------------------------------------------------------------------- ' & @CRLF)
    6. ConsoleWrite('+ Beispiel mit der Funktion Hex(), wo der Datentyp den Rückgabewert beeinflusst : ' & @CRLF)
    7. ConsoleWrite('! Hex mit Round(5.5) = ' & Hex((Round(5.5))) & @CRLF)
    8. ConsoleWrite('! Hex mit Round(5.5, 0) = ' & Hex((Round(5.5, 0))) & ' (Anm.: Hex-Repräsentation einer Gleitkommazahl)'& @CRLF)
    9. ConsoleWrite('+ --------------------------------------------------------------------------------------------------------- ' & @CRLF)

    Edit: Rechtschreibung und Formulierung und Code :D


    M

  • WinGetPos liefert nicht wie erwartet die Position und Größe des minimierten Fensters, wenn nach GUICreate('') nur ein GUISetState(@SW_MINIMIZE) ausgeführt wird, sondern die Position und Größe, welche beim Erstellen des Fenster verwendet wurde - also entweder die angegeben Werte oder die Default-Werte.


    Edit: Inspiriert durch Musashi habe ich mich entschlossen, die Examples etwas zu erweitern, damit man der Ausgabe auch gleich entnehmen kann, wo hier der Schuh drückt.


    PS: Beim Erstellen einer GUI interpretiert GUICreate die Höhe und Breite als ClientSize, WinGetPos liefert jedoch die Position und Größe inkl. Rahmen!


    Fazit: GUISetState(@SW_MINIMIZE) funktioniert nur, wenn das Fenster vorher bereits sichtbar gemacht wurde... wohingegen WinSetState($hGUI, '', @SW_MINIMIZE) aber auch funktioniert, wenn es noch nicht sichtbar ist. Sicherheitshalber sollte aber generell besser @SW_SHOWMINIMIZED als Parameter angeben werden, wenn unklar ist, ob das Fenster bereits sichtbar ist.

  • Offiziell gefixt in SciTE4AutoIt > 4.1.2 (alles nach dem 2-1-2019).

    Der Bug im Tracker wurde gefixt, die neue Betaversion stripped die Datei korrekt. Ich schätze ab dem nächsten Release sollte der Fehler behoben sein.


  • Zu : Der Au3Stripper 'parst' einige ternäre Ausdrücke nicht korrekt

    Für Nutzer*innen älterer Versionen aber nach wie vor relevant !

    86598-musashi-c64-png

    2 Mal editiert, zuletzt von Musashi () aus folgendem Grund: an neue Sachlage angepasst

  • Falls ihr _WinAPI_Path.. Funktionen verwendet, bitte sehr misstrauisch sein. Die folgenden beiden Funktionen funktionieren definitiv nicht. ***

    Dort wird ausschließlich nach Leerzeichen im Pfad gesucht und anhand dessen in Pfad und Argumente gesplittet :Face:.


    EDIT:

    ***: Wie sich herausgestellt hat, sind die _WinAPI_Path Funktionen eigentlich unschuldig. Sie erwarten einen Leerzeichen behafteten Pfad in Gänsefüßchen eingefasst. Das Hilfebsp. verwendet ungünstigerweise die Funktion _WinAPI_AssocQueryString, die Werte aus der Registry verwendet und diese sind mal mit, mal ohne Gänsefüßchen. Somit ist der Rückgabewert in der Form des Hilfebsp. nicht für die _WinAPI_Path Funktionen verwertbar.


    Lösungsvariante: