sende doch einfach ein "{tab}" nach der Auswahl eines Eintrages?
Das ist zwar ein einfacher Workaround aber ziemlich schlampig.
Ich hätte vorgeschlagen das Scrollradevent abzufragen und dann zu nullen. Man kann ja die Parameter für die nachkommenden Events glaube ich verändern,
und so würde dann das von Windows nicht mehr mitkriegen, dass gescrollt wurde.
Normalerweise macht man das mit GUICtrlSetState. Ich glaube du hast gerade einfach auf dem Schlauch gestanden, oder?
Erstell mal eine Combo und wähle einen Eintrag aus, wenn du versehentlich mit dem Rad scrollst, dann veränderst du direkt den Eintrag, da du noch den Focus drauf liegen hast.
Lies dir den Satz nochmal gründlich durch. Du schreibst, dass sich ein kompiliertes Script sich nicht anders verhält als eins, das durch den Interpreter läuft.
Das ist ja wohl selbstverständlich, der Interpreter wird beim Kompilieren beigelegt und das Script wird durch den Interpreter gejagt wenn du die "kompilierte" Exe-Datei startest.
Es macht de facto keinen Unterschied ob ich ein AutoIt-Script starte oder "kompiliere" und starte. Beides das gleiche.
also den Unterschied zu Script und Exe sehe ich eigentlich nicht. Ich glaube nicht, dass sich ein compiliertes Script anders verhällt als eines das im Interpreter läuft.
???????????????????
Mit Arrays ist das ganze so eine Friemelei, da eine Id mehrere haben kann und andere Ids weniger aber diese trotzdem die entsprechenden Indizes belegen können.
Ein ganz einfacher straight-forward Ansatz wäre es wohl ein neues Array zu erzeugen mit der Größe 0.
Das iterierst das erste Array und schaust nach ob der aktuelle Index des 1. Arrays im zweiten schon vorhanden ist.
Wenn nicht, dann ReDimst du das ganze um eins (die zweite Dimension behält die Größe!)
Dann füllst du in den entsprechenden Eintrag vom 2. Array die Id ein und trägst dahinter die Nummer ein.
Sollte schon die Id im zweiten Array existieren, dann läufst du in der zweiten Dimension einfach von links nach rechts bis du ein Feld findest welches leer ist "" oder du Out-Of-Bounds bist.
Solltest du Out-Of-Bounds sein, kannst du die zweite Dimension ReDimmen (die Einträge gehen beim Vergrößern nicht verloren) und in den letzten Eintrag eintragen.
Solltest du nicht Out-Of-Bounds sein, trägst du es einfach in das erste leere Feld ein.
Dann machst du mit dem nächsten Index des 1. Array weiter.
Das ganze wäre mit Listen viel viel schöner, aber AutoIt hat leider keine Listen. Sogar mit Dictionaries wäre das ganze schöner zu lösen.
So hätte ich das ganze gemacht (Array-Variante). Je nach Datenmenge kann das langsam laufen und es gibt definitiv bessere Implementationen aber es läuft und es ist nicht allzu kompliziert.
In [0][0] steht die Id und in [0][1] irgendeine Zahl die dahinter gepackt wird.
#include <Array.au3>
Local $a[3][2] = [["ID 001", 4], ["ID 002", 6], ["ID 001", 2.5]]
$b = _SummarizeArray($a)
_ArrayDisplay($b)
Func _SummarizeArray($a)
Local $b[0][2]
For $i = 0 To UBound($a) - 1
$bIdAlreadyExists = False
For $j = 0 To UBound($b) - 1
If $a[$i][0] = $b[$j][0] Then
$bIdAlreadyExists = True
ExitLoop
EndIf
Next
If $bIdAlreadyExists Then
; $j beinhaltet den Index der ID für das 2. Array
$bAddedSuccessfully = False
For $k = 0 To UBound($b, 2) - 1
If $b[$j][$k] == "" Then
$b[$j][$k] = $a[$i][1]
$bAddedSuccessfully = True
ExitLoop
EndIf
Next
If Not $bAddedSuccessfully Then ;Out-Of-Bounds, müssen erweitern und einfügen
ReDim $b[UBound($b)][UBound($b, 2) + 1]
$b[$j][UBound($b, 2) - 1] = $a[$i][1]
EndIf
Else
ReDim $b[UBound($b) + 1][UBound($b, 2)]
$b[UBound($b) - 1][0] = $a[$i][0]
$b[UBound($b) - 1][1] = $a[$i][1]
EndIf
Next
Return $b
EndFuncWo hast du denn deine _getAllFTPFilesRekursiv Funktion definiert?
Hat man Nachteile, wenn man nur 64bit Versionen erzeugt? (Klar die laufen nur unter 64bit OS).
Es kann bei Bugs zu Crashes bei den 64-Bit DLLCalls kommen (wie bei _GDIPlus_EffectCreate z.B.)
Der einzige "Nachteil" der mir einfällt ist, dass 64-Bit Exen größer sind aber das ist vernachlässigbarer Unterschied.
Anscheinend läuft das Skript als x64 nur mit der AutoIt Version v3.3.14.3! Muss mal prüfen, woran das liegt.
Auszug der Changelog zu 3.3.14.3: Fixed: _GDIPlus_EffectCreate() crashing when run using AutoIt x64.
Du hast Au3-Dateien mit dem Texteditor verknüpft und deswegen zeigt er es vielleicht nicht an. Normalerweise sollte da ein au3-Icon sein.
Wenn jeder der die neue Version sucht und nich findet - einen Thread aufmacht warum es keinen Link zur neuen Version gibt - haben wir Arbeit.
Das wäre dann einer bisher.
Wenn wir einen Link anbieten, der auf eine Seite von uns verweist, dort warnen wir deutlich vor der neuen Version mit dem Hinweis - doch bitte auf das Update vom Update zu warten - ohne einen Downloadlink anzubieten - haben wir alles mit ein wenig Arbeit erledigt.
Okay, sagen wir wir haben einen Link eingerichtet mit einem dicken Ausrufezeichen und rotblinkender Schrift "VERBUGGTE VERSION - DOWNLOAD AUF EIGENE GEFAHR".
Meinst du irgendjemand wird sich in zwei Wochen danach noch erinnern, dass diese Version Bugs beinhaltete?
Spulen wir 2-3 Monate vor und die Leute haben die 3.3.14.3 auf der Platte (ohne auf die 3.3.16.0 geupdatet zu haben, so handhabe ich das nämlich (ich upgrade selten!)) und versuchen dann ein Script zu basteln welches aufgrund der Bugs nicht bei jedem konsistent läuft. Dann müssen wir uns den Kopf darüber zerbrechen und immer nach der installierten AutoIt-Version fragen.
Also können wir uns doch die Arbeit einfach sparen und eine Woche länger auf die gefixte Stable warten, dann müssen wir keinen Disclaimer basteln und für einige Versionen nicht um die Ecke denken.
Ja auf welcher Seite denn? Du könntest dein Problem vielleicht mit WinHttp lösen und dann komplett auf Firefox verzichten.
Dieses Release hat viele Fixes, es lohnt sich.
Warum erscheint dieses Release noch nicht hier ?
Das ist kein guter Stable-Release, da in den UDFs viel vermurkst wurde als sie die Magic-Numbers durch Konstanten ersetzt haben.
Wir warten momentan auf die 3.3.14.4 oder 3.3.16.0 (je nach dem wie sie es nennen werden) damit die Bugs gefixt sind und eine gute Stable angeboten werden kann.
Dazu gabs auch schon einen Thread im englischen Forum und hier wurde das ganze auch schon angeschnitten (in der SB und in Threads).
https://www.autoitscript.com/forum/topic/192254-33143-fixes/
Schade, dass das Control keine Klasse hat, dann könntest du direkt die Zahlen auslesen. Probier mal mit WinGetText ob du den Wert ebenfalls bekommst.
Notfalls kann man ja einfach den Rest wegschneiden.
Was willst du denn überhaupt mit dem Linksclick erreichen? Wir können dir sicherlich eine bessere Alternative dazu geben wenn du uns verrätst was du machen möchtest.
Das wird dann wohl am Server liegen oder die Daten wurden modifiziert und mit 00:00:00 getaggt.
Änderungsdatum kriegst du ja im [3]-Index zurück, um das Datum zu extrahieren kannst du die Zeit mit den Strinfunktionen abschneiden oder die _Date'-Funktionen verwenden.
FileGetTime und FileExists kansnt du nicht verwenden, da das nur für lokale Dateien gedacht ist.
Für FileGetTime bietet sich _FTP_ListToArrayEx an, das gibt dir nämlich bei erfolgreichen Anfrage Daten im folgenden Format zurück:
$Array[0][0] = number of found entries
...
$Array[n][0] Filename
$Array[n][1] Filesize
$Array[n][2] FileAttribute
$Array[n][3] File Modification datetime
$Array[n][4] File Creation datetime
$Array[n][5] File Access datetime
Für FileExists kannst du einfach mit _FTP_ListToArrayEx oder _FTP_ListToArray2D (oder kleinschrittiger mit den _FTP_FindFileFirst, _FTP_FindFileNext) auflisten und dann das Array durchgehen und prüfen ob der Dateiname auftaucht oder nicht.
Du musst den ftp://-Header bei der Server-Adresse rausnehmen. Es ist explizit nach dem Hostnamen gefragt und nicht nach dem Protokoll.
Mit FileCopy kannst du keine Daten auf einen FTP-Server schieben (außer er ist als Netzlaufwerk angebunden).
Du musst die FTP-Funktionen verwenden, um genauer zu sein: _FTP_FileGet: https://www.autoitscript.com/autoit3/docs/l…FTP_FileGet.htm
WM_NOTIFY ist die falsche Nachricht um das Klicken eines Eintrages abzufangen, WM_COMMAND ist das was du suchst.
Damit kannst du klicks auf die ComboBox, die ImageList und beim Klicken des Eintrages abfangen. Je nachdem was passiert ist, wird der Notification Code gesetzt:
https://msdn.microsoft.com/en-us/library/…1(v=vs.85).aspx das CBN_SELCHANGE kommt als WM_COMMAND an.
#Region ;************ Includes ************
#Include <WindowsConstants.au3>
#include <GuiComboBoxEx.au3>
#include <GUIConstantsEx.au3>
#include <GuiImageList.au3>
#EndRegion ;************ Includes ************
Opt("GUIOnEventMode", 1)
$hGui = GUICreate("Test", 400, 300)
GUISetState(@SW_SHOW)
Global $idCombo = _GUICtrlComboBoxEx_Create($hGui, "", 10, 10, 170, 200, $CBS_DROPDOWNLIST)
Global $hImagelist = _GUIImageList_Create(32, 32, 5, 3)
_GUICtrlComboBoxEx_SetImageList($idCombo, $hImagelist)
_GUIImageList_AddIcon($hImagelist, "shell32.dll", 10, True)
_GUICtrlComboBoxEx_AddString($idCombo, "Test", 0, 0)
Global $idCombo2 = _GUICtrlComboBoxEx_Create($hGui, "", 10, 100, 170, 200, $CBS_DROPDOWNLIST)
_GUICtrlComboBoxEx_AddString($idCombo2, "Test")
GUISetOnEvent($GUI_EVENT_CLOSE, "_exit")
GUIRegisterMsg($WM_COMMAND, "WM_COMMAND")
While 1
Sleep(10)
WEnd
Func _exit()
Exit
EndFunc ;==>_exi
Func WM_COMMAND($hWnd, $iMsg, $wParam, $lParam)
#forceref $hWnd, $iMsg, $wParam
Local $hWndFrom, $iIDFrom, $iCode, $tNMHDR, $tInfo
ConsoleWrite("Control Identifier: " & _WinAPI_LoWord($wParam) & @CRLF)
ConsoleWrite("Notification Code: " & _WinAPI_HiWord($wParam) & @CRLF)
ConsoleWrite("Control Handle: " & $lParam & @CRLF)
ConsoleWrite(@CRLF)
Return $GUI_RUNDEFMSG
EndFunc ;==>WM_NOTIFYZuerst wird ein Thema gepostet und dann kümmert man sich nicht darum. Finde ich unsozial. Da war tubsids vor 2 Stunden online aber eine Antwort auf Aspirinjunkies berechtigte Fragen - gibt es nicht. Nicht nett.
So eng würde ich das nicht sehen, kann ja sein, dass er das ganze jetzt zusammenträgt oder keine Zeit hatte und nur checken wollte ob jemand geantwortet hat.
Wir hatten schon öfters Threads wo sich der TE, nach einer exzessiven Diskussion abseits der eigentlichen Frage (die mittendrin gelöst war), nach einer Woche gemeldet hat.