Beiträge von fakeraol

Wäre ein installiertes Java dann nicht auch Voraussetzung, damit diese Scripte dann laufen?

Wenn ich das bis hier hin richtig verstanden habe, müssen alle WinApi-Programme ihre Oberflächen mit zusätzlichen Routinen repositionieren, weil es keine positionellen Abhängigkeiten von anderen Controls gibt unter Win32?

Wäre es denn (technisch) möglich, ein anderes GUI-Toolkit per UDF für die AutoIt-GUI zu verwenden? Evtl. Tips, was sich da hinsichtlich Verbreitung auf Windows-Rechnern und Umsetzbarkeit anbieten würde? DotNet evtl.?

Oscar

Danke für den Tip, damit lässt sich der Bug (?) von ControlGetPos im Fullscreen-Modus umgehen, was allerdings nichts daran ändert, daß ControlGetPos da nicht die richtigen Werte liefert. Das sollte in der Hilfe erwähnt werden.

Nach rumspielen mit dem Beispiel von GUISetCoord verstehe ich jetzt, wie es funktioniert. Die Beschreibung bleibt selbst jetzt unverständlich.

"AutoItSetOption" > "GUICoordMode" > 2 positioniert relativ zur unteren rechten Ecke des vorhergehenden Controls. Ausnahme: mit "-1" übernimmt man die top/left-Werte des vorherigen Controls.

Um ein Control genau 1px höher/links als das vorige zu positionieren (-1 ist ja reserviert für "gleicher Abstand von oben/links"), muß man es mit negativen Werten um ("Höhe/Breite des vorigen Controls" + 1) nach oben/links verschieben/positionieren.

Ich halte es für dringend nötig, für "GUICoordMode" ein Beispielscript einzubauen, in dem alle drei Positionierungsvarianten vorgeführt werden.

zu ControlGetPos:

(resizen und beobachten, wie sich die Werte verändern und das Group-Control neu positioniert wird. Dann maximieren, und beobachten, daß das Group-Control nicht neu positioniert wird, weil ControlGetPos immer noch die gleichen Werte wie vor der Maximierung zurückliefert.)

Nach dem Restore wird Group übrigens nochmal falsch positioniert, anscheinend nach der Position , die das Input vorher, während der Maximierung hatte.

#include <GUIConstants.au3>
$MainGUI = GUICreate("", 600, 600, -1, -1,  $WS_MINIMIZEBOX + $WS_MAXIMIZEBOX + $WS_SIZEBOX)
    GUIRegisterMsg($WM_SIZE, "_WM_SIZE")
    $patternGroup = GUICtrlCreateGroup("", 10, 210, 570, 60)
    GUICtrlSetResizing (-1,$GUI_DOCKHEIGHT + $GUI_DOCKRIGHT + $GUI_DOCKLEFT)
    Global $g_idPattern = GUICtrlCreateInput("", 70, 230, 500, 30)
    GUICtrlSetResizing (-1,$GUI_DOCKHEIGHT + $GUI_DOCKRIGHT + $GUI_DOCKLEFT)
GUISetState(@SW_SHOW)
    
    
Func _WM_SIZE($hWnd, $Msg, $wParam, $lParam)
    Local $InputPos = ControlGetPos($MainGUI, "",$g_idPattern)
    GUICtrlSetData($g_idPattern, "GUICtrlGetPos( Left: "&$InputPos[0]&", Top: "&$InputPos[1]&", Width: "&$InputPos[2]&", Height: "&$InputPos[3]&")")
    Local $GroupPos = ControlGetPos($MainGUI, "",$patternGroup)
    GUICtrlSetPos($patternGroup, Default, $InputPos[1] - 18, $GroupPos[2], Default)
    Return $GUI_RUNDEFMSG
EndFunc

While GUIGetMsg() <> -3
WEnd

Noch ein Punkt:

In der Hilfe sind diverse Beispiele verlinkt, die ihre Ausgabe in die Console machen. Außer bei den Console*-Funktionen wäre es viel sinnvoller, die Ausgabe in einer MsgBox zu machen, damit Anfänger sie nach Click auf "Open this Script" auch sehen können.

Außerdem sollte bei ConsoleWrite zumindest für den auf der AutoIt-Seite empfohlenen Editor erklärt werden, wie man eine Ausgabe in die Console erreicht. In Notepad++ musste ich dazu händisch einen Button anlegen, der das Script an AutoIt übergibt. An solchen Hürden scheitert teilweise die Motivation von Anfängern, weiter zu machen.

Ja, z.B. bei "AutoItSetOption" > "GUICoordMode" > 2

Diese "cell"s tauchen da einfach so aus dem Nichts auf, und warum man für "current cell" -1,-1 statt einfach 0,0 angeben soll, ist logisch auch nicht nachvollziehbar, zumal -1 dadurch unnötigerweise für die Positionierung nicht nutzbar ist. Statt von "Zellen" zu sprechen, sollte erklärt werden, daß jedes Control relativ zum vorhergehenden ausgerichtet wird

Und daß ControlGetPos bei @SW_MAXIMIZE "falsche" Werte (die vor der Maximierung, die für @SW_RESTORE gespeichert bleiben) liefert, sollte auch erwähnt werden.

chesstiger

W32 kann Elemente nur am Fenster ausrichten, nicht an anderen Elementen? Bzw. Elemente als Kinder anderer Elemente definieren, so daß sie sich an denen ausrichten?

Tuxedo

Mit der Option GUIResizeMode kann ich auch wieder nur das Verhalten ALLER Elemente gleich festlegen, nicht aber für Buttons $GUI_DOCKSIZE als Default setzen, und für Imput, Combo, List z.B. $GUI_DOCKBORDERS.

Daß der Abstand eines, in einem Group-Control plazierten Input zu dessen Rändern sich beim Resizen verändert, kannst Du rein mit GUICtrlSetResizing nicht korrigieren. Dazu braucht es immer zusätzlichen Aufwand, z.B. mittels $WM_SIZE (was aber beim Maximieren eines Fensters nicht funktioniert, da ControlGetPos dann falsche Werte liefert).

Firefox und Interaktion mit Webseiten? Ganz ehrlich: Greasemonkey und Javascript (wenn die Weboberfläche von einer externen Firma ist), oder am besten die Webobefläche von deren Erzeuger selber optimieren lassen.

PS: Es gibt noch eine Möglichkeit, auf die Seite zuzugreifen, ohne Button-Positionen, etc. kennen zu müssen:

Über Bookmarklets, d.h., Du postest einfach einen String, beginnend mit "javascript: ... " in die Adresszeile des Browsers, mit der Du dann die Funktionen in der Seite aufrufst, bzw. Elemente der Seite ansprichst. Bei allem, was eine Rückgabe erzeugt, musst Du diese dann abfangen und unterdrücken, damit die Seite nicht neu geladen wird.

Dann also bei jedem WM_MOUSEWHEEL Event die Maus-Position über der GUI abfragen und mit dem ComboBox-Control abgleichen. Und dann entweder Control scrollen, oder GUI.

Ich hab grad versucht, den Regex-Tester aus der Hilfe resizable zu machen.

Daß Controls in AutoIt nicht mit den gebräuchlichsten Resizing-Parametern als Default-Werten erzeugt werden und man die immer erst anpassen muss, ist schade. (Buttons z.B. behalten ihre Größe in der Regel, während Imputs, Combos, Listen, etc. üblicherweise mit der Gui resizen)

Daß z.B. die (visuell) in "Groups" positionierten Controls z.T. aus diesen "herauswandern" beim Resizen, ist ärgerlich.

Wenn ich $WM_SIZE benutze, funktioniert das z.B. nicht beim Maximieren.

Wie funktioniert denn das bei Programmen, die in anderen Sprachen geschrieben wurden? Dort werden Controls doch anscheinend nicht nur am Fenster, sondern auch aneinander ausgerichtet, so daß die Margins zwischen ihnen gleich bleiben.

DotNet arbeitet z.B. mit Margin und Padding, so wie das auch in Html funktioniert. (https://msdn.microsoft.com/de-de/library/…(v=vs.110).aspx)

Gibt es in den WinApi's keine Funktionen, um die Positionierung auf die gleiche weise für AutoIt-GUIs festzulegen?

WinGetHandle("DirectorExtension") gibt @error = 1 zurück. Notepad++ hat keine DirectorExtension, die gehört zur SciTE.exe, nicht zum Scintilla-Control (dll).
Kann man denn mit WM_COPYDATA auch das Ergebnis des DLL-Calls an das AutoIt-Script umleiten, wenn Scintilla es normalerweise in den per Pointer übergebenen Buffer schreiben würde?

Ich möchte für ein kleines Hilfstool direkt mit dem Scintilla-Control in Notepad++ komunizieren. Mit allen Commands, die Werte per Return zurückgeben, funktioniert das auch. Das sind allerdings nur Integer-Werte, für Strings muß eine DLL-Struct übergeben werden und die bleibt leer. Ich vermute, daß das mit den getrennten Speicherbereichen von Prozessen zu tun hat, daß Scintilla also nicht in die von meinem Script bereitgestellte Struct schreiben kann. Gibt es dafür eine Lösung, oder ist das "by design" so gewollt, daß das nicht geht?

Könnten da vielleicht WM_COPYDATA oder das NomadMemory-UDF mir da weiterhelfen?

Beispielcode:

Global $NPPhwnd, $NPPselected
Global Const $SCI_GETSELTEXT=2161


$NPPhwnd = WinGetHandle("[Active;CLASS:Notepad++]")
Global $ScintillaClassNameNN = ControlGetFocus($NPPhwnd)
Global $ScintillaHwnd = ControlGetHandle($NPPhwnd,"",$ScintillaClassNameNN)


ConsoleWrite(SCI_GETSELTEXT($ScintillaHwnd))


Func SCI_GETSELTEXT($Sci)
	Local $ret, $sText=""
	$iLen = DllCall("user32.dll","long","SendMessageA","hwnd",$Sci,"int",$SCI_GETSELTEXT,"int",0,"int",0)
	If @error Then Return -1
	$sBuf = DllStructCreate("byte[" & $iLen[0] & "]")
	If @error Then Return -2
	$ret = DllCall("user32.dll","long","SendMessageA","long",$Sci,"int",$SCI_GETSELTEXT,"int",0,"ptr",DllStructGetPtr($sBuf))
	If @error Then Return -3
	$sText = BinaryToString(DllStructGetData($sBuf, 1))
	$sBuf = 0
	If @error Then Return -4
	Return $sText
EndFunc

Das Problem unerwarteter Hintergrundfarben von z.B. Radio- und Checkbox-Controls taucht ja immer mal wieder auf. Einfach die auf dem eigenen System verwendete Farbe als Hintergrundfarbe für solche Controls zu setzen, ist aber keine saubere Lösung, wenn man die Exe weitergeben, oder seine Systemfarben mal ändern will. Anscheinend wird da nicht die Hintergrundfarbe des darunter liegenden Controls verwendet, sondern die des zugrundeliegenden Fensters.

Ich hab konkret beim Nachbau des Notepad++ - Suchen&Ersetzen"-Dialogs versucht, zu identifizieren, welche Systemfarbe da als Hintergrundfarbe für die TabItems verwendet wird, aber ohne Erfolg. Die in Frage kommenden Systemfarben $COLOR_WINDOW und $COLOR_HIGHLIGHTTEXT zu testweise im Windows-Farben-Dialog ändern, hat den Hintergrund der TabItems nicht beeinflußt.

Eine Übersicht der jeweils verwendeten Systemfarben jedes in AutoIt verfügbaren Controls wäre mal nützlich, also pro Control die Angaben, mit welchen Systemfarben welche seiner Bestandteile dargestellt werden.

Alternativ: wie erreicht man, daß die Farbe des darunterliegenden Controls verwendet wird?

Ich hab gerade eine ganz simple Pseudo-Texterkennung gebaut. Da sich in AudaCity die Controls für Anfang und Ende einer Auswahl nicht direkt per AutoIt auslesen lassen, habe ich sie per PixelChecksum "ausgelesen":

Opt("WinTitleMatchMode",4)
;Opt("TrayIconDebug",1)
Opt("PixelCoordMode",2)
$handle = WinActivate("Vivir la Utopía")
WinWaitActive($handle,"",5)
; Checksums (Adler) als Variablennamen, jeweils erste Checksum für nicht ausgewähltes Feld,
; zweite Checksum entspricht der Farbänderung beim anclicken mit der Maus zum Editieren
$2731708797 = 0
$1249945457 = 0
$3457326344 = 1
$3546922070 = 1
$189568228 = 2
$2558045491 = 2
$2247005759 = 3
$1980280805 = 3
$941069677 = 4
$4163153477 = 4
$360354491 = 5
$2015471813 = 5
$3420688462 = 6
$2279974107 = 6
$1971952380 = 7
$401258605 = 7
$1111657628 = 8
$2478480920 = 8
$4051865454 = 9
$3387532109 = 9
$posStart = ControlGetPos($handle,"","[CLASS:wxWindowClassNR; INSTANCE:41]")
$posEnd = ControlGetPos($handle,"","[CLASS:wxWindowClassNR; INSTANCE:42]")
; welche Darstellung der Werte ist gerade eingestellt? Offsetwerte für die einzelnen Ziffern
$stepSamples = StringSplit("4,14,24,38,48,58,72,82,92",",",2)
$stepMilliseconds = StringSplit("4,14,39,49,86,96,110,120,130",",",2)
$stephhmmssSamples = StringSplit("4,14,39,49,86,96,136,146,156,166",",",2)
Dim $step
Switch $posStart[2]
Case 161 ; Samples
$step = $stepSamples
Case 173 ; Milliseconds
$step = $stepMilliseconds
Case 254 ; hhmmss+Samples
$step = $stephhmmssSamples
EndSwitch

Func read($pos)
Dim $txt
For $offset in $step
$txt &= Eval(PixelChecksum($pos[0]+$offset,$pos[1]+7,$pos[0]+$offset+7,$pos[1]+16))
Next
return $txt
EndFunc

ConsoleWrite("Start: "&read($posStart)&@CRLF&"End : "&read($posEnd)&@CRLF)

Vielleicht kann das ja jemandem als Inspiration dienen, wenn sich ein Control nicht direkt auslesen lässt.

Ja, der Blockeditor ist ein musthave, ohne den geht's garnicht.
Blockweises Editieren geht übrigens auch mit Alt + Maus, zB. 10 Zeilenumbrüche, beim ersten mit gedrücktem "Alt" clicken und bis Zeile 10 runterziehen und dann in 10 Zeilen syncron das gleiche schreiben.
Beim blockweisen Kopieren muß man beachten, daß wenn man z.B. 10 Zeilen an einer Stelle einfügen will, man vorher auch für diese 10 Zeilen Platz mit Zeilenumbrüchen schaffen muß. Sonst landet ein Teil des Eingefügten mitten in den nachfolgenden Zeilen.

Scite / Notepad++ = Scintilla hat schon echt viele geniale Features und lässt sich fast unbegrenzt erweitern durch Macros und weitere Programme, die sich per Kommandozeile steuern lassen.

Von mir aus ja. Die Zeichen sind gut unterscheidbar und die Farben zu erkennen. Ob das Eurer Vorstellung entspricht, ob Ihr es für gut verständlich haltet, müsst Ihr entscheiden.
Ich denke, damit kann man gut nachvollziehen, warum in welchen Fällen welche Zeichen wie maskiert werden.

EDIT1: ARGH!! hab grad noch 2 Fehler gefunden.
EDIT2: Fertig, geändert. Da waren noch 2 schliessende runde Klammern zu viel, vergleiche mal mit dem Bild.

Ich wollte meine Änderung oben eigentlich an den Tread anhängen.
Evtl. könnt Ihr das ja schon so übernehmen in die Hilfe.

2 Gründe gegen den Umstieg:

• Metro
• Was anscheinend die wenigsten bisher mitbekommen haben: M$ räumt sich selber in der Eula das Recht ein, nach eigenem Gutdünken und ohne Anfrage oder wenigstens Ankündigung Programme UND DIE DAMIT ERSTELLTEN DATEIEN auf dem Recher des Users fernzulöschen und wird dazu eine Schnittstelle in Win8 einbauen. Vorgeblich geht es dabei um das Entfernen von Schadprogrammen, aber ich möchte das Geschrei sehen, wenn M$ z.B. OpenOffice mal eben als Sicherheitsrisiko eingestuft und die damit erstellte Diplomarbeit 2 Tage vor dem Abgabetermin ins Nirvana befördert wird. Ich weis, wer kein Backup macht, ist selber schuld, aber was, wenn M$ Eure Lieblings-Freeware-Tools vom Rechner killt, weil Ihr die mittelmässigen M$-Tools kaufen sollt? Oder GEMAmässig Eure Musik- und Filmsammlung zensiert? Für mich ist Win7 das letzt noch brauchbare M$-System, ich orientiere mich jetzt noch mehr nach Linux.

Ich zitiere aus dem Quelltext:

<meta name="description" content="AutoIt ist eine Programmiersprache, um Vorgänge zu automatisieren. Der hauptsächliche Schwerpunkt liegt bei der Silent / unattended Installation von Programmen." />

"AutoIt ist eine Programmiersprache, um Vorgänge zu automatisieren."

Mit diesem Satz erscheint die Seite bei Google, das ist das Aushängeschild der Seite. Sorry, aber das ist schlechtes Deutsch.
Programmiersprachen dienen grundsätzlich dazu, Vorgänge zu automatisieren. Die Fremdworte im zweiten Satz sind für jemanden, dem man schon erklären muss, das AutoIt eine Programmiersprache ist, sicher nicht geeignet. um das Verständnis zu verbessern und Interesse zu wecken.
Lasst uns doch mal nach Formulierungen suchen, die besser und verständlicher beschreiben, was jemand auf dieser Seite zu erwarten hat, was er hier finden kann, warum er die Seite besuchen sollte.

Mein erster Versuch:
"AutoIt ist eine leicht zu lernende Programiersprache, mit der man Maus- und Tastatureingaben simulieren, und z.B. Programminstallationen automatisieren kann."

Sammelt mal alles, womit man AutoIt beschreiben kann und lasst uns dann schauen, wie wir das auf ein paar kompakte verständliche Formulierungen eindampfen können.
http://www.site-check.cc/themen/meta-description.html sagt dazu:

Zitat

Eine Richtlinie für die optimale Länge der Description gibt Google selbst in der Ergebnisanzeige vor: Jede Trefferbeschreibung besteht aus ca 160 - 180 Zeichen, wobei etwa in der Hälfte eine Zäsur gemacht wird. Also soll auch die Description im ersten Teil (70 - 80 Zeichen) nicht nur die wesentlichen Keywords enthalten, sondern auch zum Klick anregen. Nach einer Unterbrechung (Punkt, Komma, Rufzeichen) soll der 2. Teil die weniger wichtigen Keywords oder eventuell noch einmal das Hauptkeyword enthalten. Verwende nur Begriffe, die auch im Text der Seite vorkommen.

Ohne den Quelltext können wir nur raten:
Hast Du die Variable $COORD01 Global angelegt. oder innerhalb der Funktion ? Dann existiert sie auch nur innerhalb der Funktion.

Ich hab nach einer Möglichkeit gesucht, auch unter WinXP die BSSID aller verfügbaren Wlan-Netzwerke auszulesen.
Die DLL-Methode dazu wird unter WinXP nicht unterstützt. WMI funktioniert in diesem Fall auch nicht, weil durch einen Bug nur Garbage zurückgegeben wird.
Ich hab bei inSSIDer im Forum nachgefragt, und der spricht über Ndis direkt den Treiber an.
In der UDF-Hilfe habe ich NamedPipes-Funktionen gefunden und ich vermute, dass damit die Komunikation mit dem Treiber möglich wäre, bewege mich allerdings mangels Kenntnissen bei der Suche bisher schon wie ein Blinder, der nur durch Zufall findet, was er sucht.
Meine Kenntnisse reichen also einfach nicht aus, um zu verstehen, wie ich das angehen müsste und deshalb suche ich Hilfe von jemandem, der sich da besser auskennt.
http://www.codeproject.com/Articles/24756…ation-802-11-OI so gehts in C#, bin aber leider nicht in der Lage, das in AutoIt umzusetzen.

ja, das meinte ich.
.vtfixup [1] int32 fromunmanaged at VT_01
.data VT_01 = int32(0)
es spielt also keine rolle, in welchem format die rückgabewerte vorliegen?

allerdings stand .corflags bei mir auf 0x00000003 . habs auf 0x00000002 geändert, war das richtig?

Evtl. lässt sich das Programm dann ja auch in AutoIt umsetzen und der Source hier veröffentlichen, so dass es nicht verloren geht. ilasm.exe und fusion.dll können aus dem framework-ordner kopiert werden, nur die ildasm.exe müsste der user sich besorgen aus dem frei verfügbaren c#-sdk.