Beiträge von alpines

Ich vermute mal GUIGetMsg liefert 0 weil kein Event anliegt, da neue Variablen undefiniert sind stimmen sie mit 0 überein (es sei dem man erzwingt einen anderen Vergleich).

Du solltest generell nicht die GUIs dynamisch erzeugen, da kann sehr viel schiefgehen. Erzeuge sie vorher und zeige/verstecke sie mit GUISetState wann immer du sie brauchst.

Bevor du sie anzeigst kannst du die Daten auf der GUI setzen damit diese bereits mit den gewünschten Daten auftaucht.

Dann hast du auch nicht das Problem des Null-Events.

Oder du bastelst einen schlampigen Workaround und setzt $sButton (s ist übrigens der total falsche Präfix dafür, da dies eine Id bzw. ein Handle bzw. ein Button ist) = 1.

Deine Parameter sind falsch, der zweite Parameter ist das Working-Directory, nicht der Dritte. Setzt du als WD @WorkingDir & "\Data" schreibt er ipconfig.txt in das Data-Verzeichnis.

Da sind noch ein paar Sachen die du "lernen" kannst

Du schreibst eine UDF und da gibt es ein paar Sachen die du beachten solltest:

• Ordentlich dokumentieren (Funktionsheader, Remarks, Return Values, etc.) Du hast zwar einen Funktionsheader aber keine Return Values oder error-Codes dokumentiert. Eventuelle Abhängigkeiten durch andere UDFs (Array.au3, File.au3)
• Funktion ordentlich benennen: Du schreibst eine Inifunktion, da solltest du - wenn du keine wirklich überzeugenden Gründe hast - dich an die Standardkonvention halten. Wenn deine Funktion nun alle Schlüssel löscht und nur den Header behält solltest du sie lieber _IniClearSection oder _IniDeleteAllSectionKeys nennen. Der Underscore ist dazu da um kennzuzeichnen, dass es sich um eine UDF handelt, und der Name ist nahe an den Originalfunktionen gehalten um sich den Namen sehr einfach zu merken.
• Parameterreihenfolge sollte semantisch Sinn ergeben. Die Standardfunktionen nehmen als ersten Parameter eine Datei (wie viele Funktionen auch), denn du spezifizierst erst die Datei auf der du was anwenden möchtest, und dann gehst du tiefer und sagst welche Sektion gemeint ist.
• Errorhandling - Wenn du eine UDF wirklich "releasen" möchtest, darf sie unter keinen Umständen crashen oder unvorhersagbare Aktionen durchführen. Deshalb musst du Fehlerfälle abfangen und behandeln, vielleicht auch dementsprechende Error-Codes behandeln. Da die Error-Codes bei Inis oftmals die selben sind (Datei nicht gefunden, Sektion nicht gefunden, Sektion bereits leer) solltest du die Codes der Standardfunktionen übernehmen damit andere Nutzer sich nicht mehr merken müssen.
• #include-once muss auf jeden Fall verwendet werden. Schreibt ein User Code wobei die UDF in zwei Unterskripten includet wird wird das Skript auf jeden Fall nicht laufen, da du Funktionsduplikate hast. #include-once verhindert das, und erlaubt nur eine Instanz des Skriptes in deinem finalen Skript (welches ins Kompilat geschrieben wird).

Es gibt bestimmt noch ein paar Punkte mehr die man erwähnen könnte, aber die hier sind mir spontan ins Auge gesprungen.

Das sind alles keine festen Regeln, deine UDF funktioniert auch wenn du jede davon missachtest aber um ein bisschen Ordnung in die Sache reinzubringen sollte man diesen Konventionen folgen.

Was passt dir denn an IniDelete nicht?

Zitat von IniDelete

key [optional] The key name in the .ini file to delete. If the key name is not given the entire section is deleted. The Default keyword may also be used which will cause the section to be deleted.

Wenn du möchtest, dass der Sektionsheader erhalten bleibt (und auch in der Reihenfolge) kannst du IniWriteSection nehmen und als "data" nichts übergeben.

Kannst du das Problem vielleicht mal in ein neues Skript isolieren damit ich mir das genauer angucken kann? Ich hab keine Lust ständig nach irgendwelchen Funktionen zu fragen, das dauert einfach zu lange.

Ich schätze mal es liegt daran, dass du unterwegs noch Anwendungen startest und das Skript dann nicht vollständig terminiert weil die Child-Prozesse ja noch laufen.

Wie sehen denn die Funktionen zum Starten der Anwendungen aus?

Du kannst in AutoIt mehrere Funktionen gleichzeitig laufen lassen wenn du es willst. Aber wenn du uns nicht verrätst was dein Skript in der Funktion macht können wir dir auch nicht weiterhelfen.

Dann liegt dein Fehler in der _01_AppStarter()-Funktion die offenbar nicht richtig terminiert.

Zitat von BugFix

Was bitte soll ein CUI Fenster sein?

Er meint das CMD Fenster welches auftaucht wenn man das Script als CUI compiled.

Du hast da zwei Möglichkeiten, entweder mit SetConsoleTitle, oder mit WinSetTitle, SetConsoleTitle wäre wohl die sichere Variante.

(Der DLL Code ist aus einem Forenbeitrag geklaut)

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Change2CUI=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

If Not @Compiled Then
    MsgBox(16, "Compile Me", "Compile Me")
    Exit
EndIf

ConsoleWrite("blablubb" & @CRLF)
SetConsoleTitle("Das ist der Title der Konsole")

Sleep(1000)

Func SetConsoleTitle($sTitle)
    Return DllCall("Kernel32.dll", "bool", "SetConsoleTitleW", "wstr", $sTitle)
EndFunc

Wenn du als CUI compilest dann bleibt das Fenster nicht offen, du musst da was falsch machen, und ohne Script können wir dir nicht weiterhelfen.

Nebenbei bemerkt ginge das ganze auch mit normalen Stringfunktionen, und das sogar sehr leicht wenn in den zufällligen Strings keine Delimeter auftauchen.

Local $sSubject = "xyz1234-xyz12345-Suchstring\xyz123456"

Local $sLinks = StringLeft($sSubject, StringInStr($sSubject, "\", 1, -1) - 1)
Local $sErgebnis = StringTrimLeft($sLinks, StringInStr($sLinks, "-", 1, 2))

ConsoleWrite($sErgebnis & @CRLF)

So vielleicht? https://regex101.com/r/VAsnZ5/1

Zitat von Hamburgo

Ich glaube, ich brauche einen Befehl, um nach einigen Zeilen das Fenster nach unten zu scrollen.

Mit welchem Befehl kann ich das Fenster nach unten scrollen ?

Ein Blick in die WebDriver Doku hätte dir die Antwort gegeben. Du kannst sogar direkt zu einem Element scrollen statt nur die Seite zu scrollen.

Zitat von https://www.w3.org/TR/webdriver1/#elements

To scroll into view an element perform the following steps only if the element is not already in view:

1. Let options be the following ScrollIntoViewOptions:"behavior""instant"Logical scroll position "block""end"Logical scroll position "inline""nearest"
2. On the element, Call(scrollIntoView, options).

Sollte das zu kompliziert sein kannst du versuchen Javascript Code über die UDF auszuführen und dann einfach mit standard Javascript Code zu scrollen.

Ein Blick in die Hilfe hätte ausgeholfen: https://www.autoitscript.com/autoit3/docs/l…tToArrayRec.htm

Multiple filters must be separated by ";" also *.txt;*.doc

Lottich wieso hast du dafür eigentlich eine UDF gebraucht, mir fällt das grad erst jetzt auf.

Wenn du nicht explizit regexen willst und nur mehrere Endungen brauchst tuts die Standard-UDF es doch auch.

rel: Regex "Multipattern" möglich?

Zitat von AutoMit

(B) Was ist der einfachste Weg, um aus 2 Arrays 1 sortiertes Array zu machen, wenn die interne Struktur wie im obigen Beispiel indentisch ist?

Beide zusammenfügen. Entweder manuell oder mit _ArrayAdd. Danach nach belieben _ArraySort verwenden.

Musst aber aufpassen, dass dann in [0] nicht die Größe enthalten ist, da diese falsch sortiert wird bzw. du danach auch noch zwei Größen hast.

Ich verstehe nicht wie du mit _InetGetSource Daten absendest. Du fordest damit nur eine Datei an.

Wie schaut denn deine php aus? Erzeugt diese dann die Datenbankeinträge wenn du _InetGetSource aufrufst?

Du schreibst ständig was von INSERT und UPDATE aber lieferst uns keine Hinweise wo das passiert, geschweige denn wie das passiert.

Zitat von super47

ich will aber nicht am PC sitzen und immer wieder abfragen ob das nu 1 ist ?

Dann musst du das in deiner php bewerkstelligen, dein Skript sollte nur einmal die Abfrage abschicken und die php sollte dann diese Abfragen verwalten.

Dann muss das Skript auch nicht die ganze Zeit warten bis geschrieben worden ist.

Speichere doch mit dem php-Skript alle Daten von den Clients ab und dann fang an sie zu inserten bzw. upzudaten.

Du zeigst uns doch nicht mal deine Datenbank, deine Codeschnipsel sind auch nicht hilfreich.

_InetGetSource liefert keine 1 zurück sondern den Quellcode zum Dokument, d.h. deine Abfrage ist schon falsch.

Zitat von super47

der spieler der update machen will muss erst wissen ob kurt einen eintrag gemacht hat ?

Das scheint ja deine InetGetSource-Abfrage zu sein, dort musst du prüfen ob das Dokument existiert oder nicht.

Ich verstehe dein Problem nicht.

Oscar einmal bitte moven.

Da du uns deine Datenbankstruktur nicht gezeigt hast und dein Codeschnipsel ehrlich gesagt uns auch nicht weiterhilft können wir dir nur rudimentär aushelfen.

Wenn du möchtest, dass 'weber' wartet bis 'kurt' die Datenbankeinträge geschrieben hat, so solltest du mit 'weber' prüfen ob er sie zu Ende geschrieben hat.

Du weißt ja wer alles im Spiel vorhanden ist, also muss 'weber' warten, biss 'kurt' alle Einträge für turnier1 (für alle Spieler) erzeugt hat, dann kann 'weber' updaten.

Wenn das nicht möglich ist, kannst du noch immer eine Spalte extra einfügen mit der Bezeichnung 'canUpdate' (oder ähnlich) wo 'kurt' dann diese Spalte 1 oder true setzt wenn 'weber' updaten darf.

Schau dir mal die WM_SIZE Dokumentation an: https://docs.microsoft.com/en-us/windows/…/winmsg/wm-size

lParam

The low-order word of lParam specifies the new width of the client area.

The high-order word of lParam specifies the new height of the client area.

Dort sind die entsprechenden Werte gespeichert, um allerdings die WindowMessages allgemein zu halten und so kompakt wie möglich zu gestalten hat man sich entschieden,

in eine Variable zwei Werte zu packen.

lParam ist ein DWORD, also 32-Bit Integer. Man teilt diesen 32-Bits einen Hi(gh) und Lo(w)-Bereich zu.

DWORD = 32 Bit (double Word)

WORD = 16 Bit (double Byte)

Byte = 8 Bit

00000000 00000000 00000000 00000000 = lParam (32-Bit)

--------- HIGH ---------- ----------- LOW ----------

Somit stehen im High 16-Bit und im Low ebenfalls 16-Bit zur Verfügung.

16-Bit sind 2 Byte, d.h. der Zahlenraum erstreckt sich von -65536 bis +65535.

Der Grund warum man hier beides in eine Variable stopft ist der, dass Fenster - für gewöhnlich - nicht bis 65000+ Pixel langgezogen werden.

Das selbe Vorgehen kann man nochmal in HiByte/LoByte unterteilen, dort werden die 16-Bit Teile analog zum 32-Bit aufgeteilt, nur in 8-Bit Blöcken.

Deine Buffer sind falsch. Es wird ein void* erwartet, d.h. du übergibst einen Pointer der auf ein unbestimmtes Datenfeld zeigt, der Typ kann nachträglich zu int, char, was auch immer gecastet werden.

Was du übergibst ist ein void**. Schau dir an was in den Funktionen davon als Buffer verwendet wird (ich schätze mal int[] oder char[] respektive byte[]) und erzeug daraus ein Struct wessen Pointer du übergibst.

Das gilt sowohl für pWBuffer als auch für pRBuffer.

Dein Parametertyp vom 1. Parameter ist "unit". Du hast einen Tippfehler drin.

WinMove doch das Childfenster wenn dein Parent ein WM_SIZE bekommt.

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <AutoItConstants.au3>
#include <WinAPI.au3>

#RequireAdmin

$hGUI = GUICreate("Form1", 615, 438, 192, 124, BitOR($GUI_SS_DEFAULT_GUI,$WS_SIZEBOX,$WS_THICKFRAME))
GUISetState(@SW_SHOW)

GUIRegisterMsg($WM_SIZE, WM_SIZE)

$iPID = Run('"' & @ComSpec & '" /c diskmgmt.msc', "", @SW_HIDE, $STDERR_CHILD + $STDOUT_CHILD)
ProcessWaitClose($iPID)

WinWait("[CLASS:MMCMainFrame]")
$hChild = WinGetHandle("[CLASS:MMCMainFrame]")

_WinAPI_SetParent($hChild, $hGUI)

While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
        Case $GUI_EVENT_CLOSE
            Exit

    EndSwitch
WEnd

Func WM_SIZE($hWnd, $iMsg, $wParam, $lParam)
    Switch $hWnd
        Case WinGetHandle($hGUI)
            Local $widthClient = _WinAPI_LoWord($lParam)
            Local $heightClient = _WinAPI_HiWord($lParam)

            Local $aPos = WinGetPos($hChild)
            Local $hParentPos = WinGetPos($hGUI)
            $aPos[0] -= $hParentPos[0] + 8
            $aPos[1] -= $hParentPos[1] + 30

            WinMove($hChild, "", $aPos[0], $aPos[1], $widthClient, $heightClient)

    EndSwitch

    Return $GUI_RUNDEFMSG
EndFunc