der Dreher von width, height und left, top war das Problem
MIt dem Fehler bist du nicht allein - und du wirst ihn auch in 10 Jahren das eine oder andere Mal wiederholen. Denn er ist sehr tückisch in der AutoIt-Syntax "vorhergesehen". Bei Erstellung der GUI wird zuerst width, height und dann left, top angegeben, bei GUI-Ctrl entgegengesetzt erst left, top und dann width, height. Darüber zu stolpern ist also gar nicht so selten. 
Du hast noch einen kleinen Fehler drin... denn hinter einer Zahl wird kein Leerzeichen ($iMinSpace = 2) eingefügt, wenn der darauf folgende Parameter ein String ist.
Stimmt, korrigiere ich gleich mal.
Wobei ich generell die Ausgabe lieber selbst formatiere, weil sie nur dann genau so ist, wie ich sie haben will...
Das stimmt natürlich. Gerade bei einem Mix von Ausgaben unterschiedlicher Längen ist eine exakte Formatierung sinnvoll.
Mir ging es hauptsächlich um Debugging von nummerischen Werten (z.B. Fenster-/Ctrl-Positionen) die bei ähnlicher Größenordnung in Schleifenausgabe auch ordentlich lesbar sind.
Das hängt wohl mit den TAB-Positionen zusammen, oder habe ich da was falsch verstanden ?
Korrekt, MinSpace ist der Abstand zwischen letztem Zeichen Wert_1 und erstem Zeichen Wert_2 (wobei das erste Zeichen des Folgewertes ein Leerzeichen ist, wenn ein nummerischer Wert folgt). Die Tabpositionen dienen der Ausrichtung, MinSpace ist für die "Luft zwischen den Werten zuständig, kann man normalerweise bei 2 oder 1 belassen.
Zum Debuggen ist es ganz praktisch, wenn man eine (beliebige) Anzahl Parameter halbwegs geordnet am Stück ausgeben kann. In Lua gibt es die Funktion print(param_1, param_2, .. param_n). Das ist praktisch, da man z.B. bei der Prüfung von Funktionen einfach die kpl. Parameterliste im Funktionskopf kopiert, in print() einmal in Gänsefüßchen einfasst, dann ein Komma und dann das ganze in Parameterform nochmal - fertig ist die Debugzeile.
In AutoIt müssen wir da etwas mühsam die Variablen verketten.
Ich habe das print() aus Lua mal in AutoIt nachempfunden für bis zu 20 Parameter. Die Ausgabe erfolgt ausgerichtet an den TAB-Positionen. Text wird links ausgerichtet, Zahlenwerte rechts. Es wird dazu die SciTE-Einstellung für die TAB-Weite ausgelesen, kann ja individuell variieren. Für den Mindestabstand von zwei ausgegebenen Werten gibt es eine Konstante $iMinSpace (vorbelegt mit 2). Wer mag, kann das für sich anpassen (Da es eine Konstante ist, erfolgt aber nicht extra eine Gültigkeitsprüfung - kleiner 1 ist sinnfrei). Der Platz zwischen zwei Werten ist immer mindestens $iMinSpace breit. Ist diese Position keine TAB-Position, wird bis zum folgenden TAB erweitert.
Wenn ich jetzt mit _Print() sich ändernde Zahlenwerte in einer Schleife ausgeben lasse, sind die Ausgaben schön geordnet ohne viel Aufwand.
$a = 123
$b = 456
$c = 789
$d = 111
$e = 222
For $i = 0 To 3
_Print('$a,$b,$c,$d,$e',$a*10^$i,$b*10^$i,$c*10^$i,$d*10^$i,$e*10^$i)
Next
; #FUNCTION# ====================================================================================================================
; Name ..........: _Print
; Description ...: Ausgabe von bis zu 20 Werten in die Konsole, ausgerichtet an den TAB-Positionen.
; Textwerte werden links, Zahlen rechts an der TAB-Position ausgerichtet.
; Syntax ........: Print($0[, $1 = Null[, $2 = Null[, $3 = Null[, $4 = Null[, $5 = Null[, $6 = Null[, $7 = Null[,
; $8 = Null[, $9 = Null[, $10 = Null[, $11 = Null[, $12 = Null[, $13 = Null[, $14 = Null[, $15 = Null[,
; $16 = Null[, $17 = Null[, $18 = Null[, $19 = Null]]]]]]]]]]]]]]]]]]])
; Parameters ....: $0 - Erster auszugebender Wert.
; $1 - [optional] zweiter
; ... bis
; $19 - [optional] zwanzigster Wert.
; Return values .: None
; Note ..........: Der Mindestabstand zwischen zwei Werten ist 2 Zeichen und kann bei Bedarf über die Konstante $iMinSpace angepasst werden.
; Author ........: BugFix
; ===============================================================================================================================
Func _Print($0, $1=Null, $2=Null, $3=Null, $4=Null, $5=Null, $6=Null, $7=Null, $8=Null, $9=Null, $10=Null, $11=Null, $12=Null, $13=Null, $14=Null, $15=Null, $16=Null, $17=Null, $18=Null, $19=Null)
Local Const $sPathUser = @UserProfileDir & '\AppData\Local\AutoIt v3\SciTE\SciTEUser.properties'
Local Const $sPathGlobal = StringLeft(@AutoItExe, StringInStr(@AutoItExe, '\', 1, -1)) & '\SciTE\SciTEGlobal.properties'
Local Const $iMinSpace = 2 ;-- Mindestabstand zwischen zwei Werten
Local Static $iSize = Null, $sSpaces = ' '
Local $sRead, $aResult
If $iSize = Null Then
$sRead = FileRead($sPathUser)
$aResult = StringRegExp($sRead, '(?m)^tabsize=(\d)', 1)
If Not IsArray($aResult) Then
$sRead = FileRead($sPathGlobal)
$aResult = StringRegExp($sRead, '(?m)^tabsize=(\d)', 1)
If Not IsArray($aResult) Then
$iSize = 4
Else
$iSize = $aResult[0]
EndIf
Else
$iSize = $aResult[0]
EndIf
EndIf
Local $aP[] = [$0, $1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16, $17, $18, $19]
Local $iLen, $iPos, $iIdx, $iLenTab, $iSpace, $sOut, $TypeLast = 'str'
For $i = 0 To 19
If $aP[$i] = Null Then ExitLoop
$iLen = StringLen($aP[$i])
$iPos = $iLen + $iMinSpace ;-- Länge und Abstand zum nächsten Wert
$iIdx = Ceiling($iPos/$iSize) ;-- der nächste TAB
$iLenTab = $iIdx*$iSize ;-- Länge mit nächster TAB-Position
$iSpace = $iLenTab - $iLen ;-- Leerzeichen zum Auffüllen
If IsString($aP[$i]) Then ;-- String linksbündig ausgeben
If $TypeLast = 'num' Then $sOut &= StringLeft($sSpaces, $iSize)
$sOut &= $aP[$i] & StringLeft($sSpaces, $iSpace)
$TypeLast = 'str'
Else
$sOut &= StringLeft($sSpaces, $iSpace) & $aP[$i]
$TypeLast = 'num'
EndIf
Next
ConsoleWrite($sOut & @CRLF)
EndFunc ;==>_PrintEDIT: Korrektur Ausgabefehler, wenn STR nach NUM folgt.
und für diese sogar temporär in den GUIMsg Modus wechselt.
Genau, so löst man das Problem, indem man die Auswerteroutinen trennt. In UDF sollte man interne Schleifen mit GUI-Auswertung immer in einem definierten Modus ausführen, d.h. gezielt zum OnEvent oder GuiGetMessage und nach Beenden zurück in den vorigen (vom User genutzen) Modus schalten. Ein Bsp. dafür ist z.B. _ArrayDisplay()
Ich würde jetzt auch nicht mehr allzuviel Energie dafür aufwenden, warum in einem mit Fehlern behafteten Skript etwas nicht funktionierte. - Gleich die Fehlerquellen beseitigen.
If Not WinActive($hGUI_Menu) sollte doch genauso in der zweiten Schleife funktionieren.
Du hast den OnEventMode, dem es gewisssermassen schnurz ist, welche Schleife läuft, wenn ein Event ausgelöst wird. Aber da du in einem Outerloop & Innerloop läufst, ist niemals sicher welchem Event jetzt Vorrang gegeben wird. Saubere Trennung der Abläufe, damit DU genau weißt, was wann passieren muss und dein Skript das verarbeiten kann.
Jetzt würde ich gerne verstehen warum dieses Verhalten passiert, denn erklären kann ich es mir nicht.
Kurz und knapp, gefunden hast du es ja selbst:
Sowie du eine Funktion aufrufst, die eine (unendliche) Schleife ausführt, hast du natürlich nur noch ein 'Leben' in dieser Schleife. Du bist in der Funktion gefangen, keine anderen Ereignisse können registriert werden. Da hebelst du selbst die OnEvent-Funktionalität aus.
Es darf nur eine MainLoop geben. In der ist alles abzuarbeiten.
Meiner Meinung nach bist du ein (deutscher) Troll. Warum?
1. Kein Ausländer meldet sich extra auf einem deutschen Programmierforum an, um im OffTopic eine iPad-Frage zu stellen.
2. Kein Nichtdeutscher (-Österreicher/-DeutschSchweizer) verwendet freiwillig eine Deutsche Tastatur und setzt dann in englischen Worten Umlaute ihrem Klang gemäß ein (Ständing statt Standing).
Ergo: Du bist deutsch, du bist ein Troll - troll dich.
Offiziell gefixt in 3.3.10.0:
Listview-UDF:
_GUICtrlListView_SortItems() sortiert lParam
_GUICtrlListView_SimpleSort() sortiert lParam nicht
EDIT:
Ich muss gestehen, dass ich nach Ablehnung meines Feature Requests dieses Thema nach 2 Jahren nicht weiter in den Changelogs verfolgt habe. Dadurch ist mir entgangen, dass das Problem (mit nahezu identischer Übernahme meiner Korrektur) in v3.3.10.0 gefixed wurde.
Also Sorry für die ungewollte Falsch-Info.
Auf das Problem wird man eher selten stoßen, aber dann fliegt es einem um die Ohren.
lParam ist wunderbar geeignet, um zusätzliche Informationen zu einem Listview-Item zu speichern (Bei Item, die mit nativen Funktionen erstellt wurden, ist lParam die Item-ID). In meiner UDF zum Formatieren von Listviews, hatte ich dort den Verweis auf ein Array-Index für das Item abgelegt, damit ich aus dem Array alle Infos zu Font, Farbe etc. verfügbar hatte. Nachdem ich das Listview mit SimpleSort sortiert hatte, funktionierte die Zuordnung nicht mehr. Da ich in der Entwicklung der UDF war, dachte ich, ich hätte in der Arrayverwaltung einen Fehler eingebaut. Tatsächlich habe ich nochmals Schritt für Schritt alles neu entwickelt um zum selben Ergebnis zu kommen. Da ging mir dann auf, dass der Fehler in der Listview-UDF liegt.
_GUICtrlListView_SimpleSort() sortiert nicht lParam! Das wurde bei der Erstellung der Funktion einfach vergessen. Ich hatte das als Bug gemeldet - wurde aber nicht für voll genommen. 
Darum hier meine korrigierte Variante von _GUICtrlListView_SimpleSort():
Func __GUICtrlListView_SimpleSort($hWnd, ByRef $vDescending, $iCol) ; modified to sort also IParam
Local $x, $Y, $Z, $b_desc, $columns, $items, $v_item, $temp_item, $iFocused = -1
Local $SeparatorChar = Opt('GUIDataSeparatorChar')
If _GUICtrlListView_GetItemCount($hWnd) Then
If (IsArray($vDescending)) Then
$b_desc = $vDescending[$iCol]
Else
$b_desc = $vDescending
EndIf
$columns = _GUICtrlListView_GetColumnCount($hWnd)
$items = _GUICtrlListView_GetItemCount($hWnd)
For $x = 1 To $columns
$temp_item = $temp_item & " " & $SeparatorChar
Next
$temp_item = StringTrimRight($temp_item, 1)
Local $a_lv[$items][$columns + 2], $i_selected ; add column for IParam ### MODIFIED ###
$i_selected = StringSplit(_GUICtrlListView_GetSelectedIndices($hWnd), $SeparatorChar)
For $x = 0 To UBound($a_lv) - 1 Step 1
If $iFocused = -1 Then
If _GUICtrlListView_GetItemFocused($hWnd, $x) Then $iFocused = $x
EndIf
_GUICtrlListView_SetItemSelected($hWnd, $x, False)
For $Y = 0 To UBound($a_lv, 2) - 3 Step 1 ; ### MODIFIED ###
$v_item = StringStripWS(_GUICtrlListView_GetItemText($hWnd, $x, $Y), 2)
If (StringIsFloat($v_item) Or StringIsInt($v_item)) Then
$a_lv[$x][$Y] = Number($v_item)
Else
$a_lv[$x][$Y] = $v_item
EndIf
Next
$a_lv[$x][$Y] = $x
$a_lv[$x][$Y+1] = _GUICtrlListView_GetItemParam($hWnd, $x) ; ### NEW ###
Next
_ArraySort($a_lv, $b_desc, 0, 0, $iCol)
For $x = 0 To UBound($a_lv) - 1 Step 1
For $Y = 0 To UBound($a_lv, 2) - 3 Step 1 ; ### MODIFIED ###
_GUICtrlListView_SetItemText($hWnd, $x, $a_lv[$x][$Y], $Y)
Next
_GUICtrlListView_SetItemParam($hWnd, $x, $a_lv[$x][$Y+1]) ; ### NEW ###
For $Z = 1 To $i_selected[0]
If $a_lv[$x][UBound($a_lv, 2) - 2] = $i_selected[$Z] Then ; ### MODIFIED ###
If $a_lv[$x][UBound($a_lv, 2) - 2] = $iFocused Then ; ### MODIFIED ###
_GUICtrlListView_SetItemSelected($hWnd, $x, True, True)
Else
_GUICtrlListView_SetItemSelected($hWnd, $x, True)
EndIf
ExitLoop
EndIf
Next
Next
If (IsArray($vDescending)) Then
$vDescending[$iCol] = Not $b_desc
Else
$vDescending = Not $b_desc
EndIf
EndIf
EndFunc ;==>__GUICtrlListView_SimpleSortIch bin mal über GUID gestolpert und habe festgestellt, dass Windows dafür noch weitere Möglichkeiten anbietet, ausser der in der WinAPICom.au3 hinterlegten Funktion.
Die Objektvariante ist mein Favorit.
Func _GUID_OLE32() ; = _WinAPI_CreateGUID()
Local $tGUID = DllStructCreate("struct;ulong Data1;ushort Data2;ushort Data3;byte Data4[8];endstruct")
Local $aReturn = DllCall('ole32.dll', 'long', 'CoCreateGuid', 'struct*', $tGUID)
$aReturn = DllCall('ole32.dll', 'int', 'StringFromGUID2', 'struct*', $tGUID, 'wstr', '', 'int', 65536)
Return $aReturn[2]
EndFunc
Func _GUID_RPCRT4()
Local $tGUID = DllStructCreate('ulong Data1;ushort Data2;ushort Data3;char Data4[8]')
Local $aReturn = DllCall('RPCRT4.dll', 'int', 'UuidCreate', 'ptr', DllStructGetPtr($tGUID))
;~ $aReturn = DllCall('RPCRT4.dll', 'int', 'UuidToString', 'ptr', $aReturn[1], 'str*', Null)
$aReturn = DllCall('RPCRT4.dll', 'int', 'UuidToStringW', 'ptr', $aReturn[1], 'wstr*', Null)
Return StringFormat('{%s}', StringUpper($aReturn[2]))
EndFunc
Func _GUID_TypeLib()
Local $oTypeLib = ObjCreate("Scriptlet.TypeLib")
Return $oTypeLib.GUID
EndFunc
ConsoleWrite(_GUID_OLE32() & @CRLF)
ConsoleWrite(_GUID_RPCRT4() & @CRLF)
ConsoleWrite(_GUID_TypeLib() & @CRLF)Schau mal in die Registierung unter HKEY_CLASSES_ROOT. Dort hast Du alle Dateitype die Assoziiert werden...
Hat aber nichts mit der Eigenschaft "Typ" zu tun (Textdokument o.ä.). Wie man das abfragen kann habe ich ja in Beitrag #10 gezeigt.
Mein Desktop ist dafür zu nackig. Habe gerade nachgesehen - meine Links/Dateien sind nicht auf dem User-Desk, sondern immer auf Admin Public. (Diesen Fall solltest du dann wohl auch berücksichtigen, wenn es allgemeingültig werden soll).
Hiermit könntest du Glück haben:
$oWShell = ObjCreate("Wscript.shell")
$objFSO = ObjCreate("Scripting.FileSystemObject")
$sFolder = $oWShell.SpecialFolders("Desktop")
$colFiles = $objFSO.GetFolder($sFolder).Files
For $objFile In $colFiles
ConsoleWrite($objFile.name & @CRLF)
ConsoleWrite($objFile.path & @CRLF)
ConsoleWrite($objFile.type & @CRLF)
NextIch verstehe nicht, wo die Daten herkommen sollen. Dein Codebsp. liefert bei mir nichts.
Ich halte das ganze Unterfangen für nicht erfolgversprechend. Dateierweiterungen haben nur bedingt etwas mit dem Inhalt zu tun. Das beste Bsp. ist doch *.au3. Je nachdem, wie du es installiert hast, wird die Datei als Text zum Bearbeiten im Editor betrachtet oder als 'AutoIt'-Datei die mit Interpreter ausgeführt wird.
Ganz zu Schweigen von frei vergebenen Dateiendungen, die der Entwickler z.B. als Ansammlung binärer Zeichen in eine Datei schreibt, die nur er auslesen kann.
Probier mal so:
;~ Func _InternetGetCookieW($sUrl, $iBufferSize = 2048) ; WinINet: https://docs.microsoft.com/en-us/windows/desktop/api/wininet/nf-wininet-internetgetcookiew
Func _InternetGetCookieW($sUrl) ;, $iBufferSize = 2048) ; WinINet: https://docs.microsoft.com/en-us/windows/desktop/api/wininet/nf-wininet-internetgetcookiew
Local $aResult
Local $iLenUrl = StringLen($sUrl)
Local $tUrl = DllStructCreate('wchar['& $iLenUrl+1 &']')
DllStructSetData($tUrl, 1, $sUrl & Chr(0))
; get buffersize
Local $tBuffersize = DllStructCreate('int')
$aResult = DllCall("Wininet.dll", 'int', 'InternetGetCookieW', _
'ptr', DllStructGetPtr($tUrl), _ ; A pointer to a null-terminated string that specifies the URL for which cookies are to be retrieved.
'ptr', Null, _ ; Not implemented.
'ptr', Null, _ ; A pointer to a buffer that receives the cookie data. This parameter can be NULL.
'ptr', DllStructGetPtr($tBuffersize)) ; A pointer to a variable that specifies the size of the lpszCookieData parameter buffer, in TCHARs.
; If the function succeeds, the buffer receives the amount of data copied to the lpszCookieData buffer.
; If lpszCookieData is NULL, this parameter receives a value that specifies the size of the buffer
; necessary to copy all the cookie data, expressed as a byte count.
ConsoleWrite('Buffersize: ' & DllStructGetData($tBuffersize,1) & @CRLF)
; get cookie data
Local $tCookieData = DllStructCreate('wchar['& DllStructGetData($tBuffersize,1)+1 &']')
$aResult = DllCall("Wininet.dll", 'int', 'InternetGetCookieW', _
'ptr', DllStructGetPtr($tUrl), _
'ptr', Null, _
'ptr', DllStructGetPtr($tCookieData), _
'ptr', DllStructGetPtr($tBuffersize))
ConsoleWrite(DllStructGetData($tCookieData,1) & @CRLF)
EndFuncEDIT: Habe es erst jetzt testen können - bekomme keine Fehler, aber auch keine Werte von der Funktion. Auf den ersten Blick fällt mir jetzt nicht auf, weshalb.
Aber auf den zweiten: Die Funktion kann bei mir nichts zurückgeben - ich habe keine Cookies, die der Vorgabe entsprechen (Ablaufdatum in der Zukunft). Vermutlich, weil nur Daten des IE verwendet werden - somit ist diese Funktion geradezu unnütz.
Du hattest den Fehler, weil du das Null-terminiert nicht beachtet hast. Daten vom Typ wchar sind immer Null-terminiert, d.h. sie müssen mit einem Chr(0) am Ende markiert werden. Dieses zusätzliche Zeichen muss man dann natürlich auch bei der Länge des vorbereiteten Puffers beachten.
Alternativ kann man übrigens Cookies recht simpel aus ihren Verzeichnissen auslesen.
Meiner Logik nach, muss ich doch in dem Feld erst schauen, ob ein Komma vor kommt, falls ja, dann dieses Komma mit einem Punkt austauschen.
Das macht StringReplace für dich. Wenn das gesuchte Zeichen nicht vorkommt, wird der Originalstring zurückgegeben.
Einfach mal rumprobieren: ConsoleWrite(StringReplace('123.45', ',', '.') & @CRLF)
Ich dachte die Control-ID wäre die Variable, welche ich davor schreibe.
Ja, völlig richtig. Aber die hat natürlich nur einen Wert während das Skript läuft - den von der Erstellung.
Mit dieser ID hast Zugriff auf das Control selbst und kannst dessen Inhalt auslesen, indem du die ID als Parameter an die Auslesefunktion übergibst (GuiCtrlRead($ID)).
Mit der ID hast du auch die Möglichkeit den Status (show, hide, enabled, disabled) zu ändern, oder Farbe, font etc. pp.
Viel Erfolg beim Lesen.
Bei Select wärst du damit aus meiner Sicht auf der sicheren Seite UND wenn er ein passendes Case gefunden hat, prüft er nicht weiter.
Das ist etwas fehlinterpretiert und verwirrt den TE sicher mehr, als das es hilft.
Der eigentliche Unterschied ist der:
SELECT:
- jedes Case hat irgendeinen oder eine Kombination von Werten die geprüft werden sollen (vergleichbar mit einer If..ElseIf..ElseIf..ElseIf-Struktur)
SWITCH
- EIN Wert wird mit verschiedenen Zuständen (in jeweils einem Case) abgeglichen.
Da der User ausschliesslich den GuiGetMsg-Wert prüft, ist Switch durchaus angemessen.
Möglich ist natürlich beides.
Da (s. Post #6) hatte ich übrigens noch ein paar Fehler drin, die ich nun aber korrigiert habe.
Und neue eingebaut. 
Das Auslesen der properties (_GetProperty) führt jetzt immer zum Ergebnis "0" und _GetCurrentFile bringt kein Ergebnis. _WinAPI_MultiByteToWideChar ist dort also nicht sinnvoll, da es das Ergebnis "frisst".
Local $Berechnung = $Formnestzahl + $Zykluszeit
Lerne draus, ist ein typischer Anfängerfehler:
Die Variablen $Formnestzahl & $Zykluszeit speichern jeweils die ID des Inputs und NICHT dessen Inhalt.
An den Inhalt gelangst du mit: GuiCtrlRead($ID). Aber erst abfragen, wenn auch der Inhalt geändert wurde.
Etwas Anderes ist es, wenn du mit einer InputBox() arbeiten würdest. Die poppt auf und fordert eine Eingabe und gibt dann den eingegebenen Inhalt zurück.
Es gibt eine interne Bufferverwaltung, damit werden ja die Tabs mit Index versehen und auch (irgendwo) gespeichert, denn nach Neustart SciTE sind die Buffer in gleicher Reihenfolge geöffnet, ohne eine Session zu speichern.
Alternativ kann man natürlich eine eigene Bufferverwaltung erstellen, die Events für Öffnen, Schließen, Löschen, Verschieben liefert SciTE. Smarter wäre aber, wenn man das vorhandene nutzen könnte. Wenn ich etwas Muße habe, werde ich mal einen Blick in die Scintilla Source werfen. Vielleicht kann ich da etwas finden.
