@ BiNu
Viele Dank für die kreative (und praktische) Lösung. Ich
werde sie mit einbeziehen, wenn ich es mit AutoIt nicht gelöst werden kann.
@Homelike Jester
Ich habe mir mal ein paar Thread hierzu im Forum angeschaut.
Es scheint so, dass es nicht nur kompliziert ist, sondern, dass es Probleme
beim Durchsatz geben könnte. Ich werde mich mal weiter informieren und ggf.
testen.
Grüße
Mike 
GW2 hat zwar eine Fensterfunktion, aber dann gehen mein fps deutlich runter und ich kann den Gamma-Wert nicht mehr einstellen. Von daher ist diese leider nicht so geeignet.
Thanks für die Hinweise! Leider habe ich von so etwas keine Ahnung und weiß auch nicht, wie ich das zweite laufende Programm (Eventtimer) mit einem EndSceneHook drüber legen kann. 
Grüße
Mike
@ Alpines,
was meinst du damit? Könntest du mir dies kurz etwas näher erläutern?
Gibt es ggf. eine Lösung?
Thx!
Grüße
Mike
Hei,
ja habe ich. Ich habe dagegen nicht verstoßen. Es handelt sich um das Spiel "Guild Wars2" und um ein offizielles Programm (Eventanzeiger), welches jeder User ganz normal benutzen kann. Es soll einfach darüber gelegt werden, damit man es normal im Blick hat. Mehr nicht. Es ist kein Bot oder etwas ähnliches. Mich nervt es halt einfach, dass man entweder GW2 als Fenster laufen lassen muss oder immer umswitchen muss.
Grüße
Mike
Es gibt nur wenige Programme, die im Vollbild-Modus laufen, und während dessen anderen Programmen (indirekt) das Anzeigen verwähren.
Denn solche Programme müssen meist direkt auf die Grafikhardware via DirectX oder OpenGL zugreifen... Nämlich Spiele.Und daher... Hast du unsere Es gibt nur wenige Programme, die im Vollbild-Modus laufen, und während dessen anderen Programmen (indirekt) das Anzeigen verwähren.
Denn solche Programme müssen meist direkt auf die Grafikhardware via DirectX oder OpenGL zugreifen... Nämlich Spiele.Und daher... Hast du unsere Forenregeln gelesen?
Ich möchte über ein Programm, welches nicht in einem Fenster, sondern als Vollbild läuft, gerne ein anderes Programm, welches ein Fenster darstellt, legen (Topmost). Das geht jedoch trotz des Flags nicht. Wie bekomme ich ein Fenster/Programm über das 1. Programm gelegt, weenn es als Vollbild (nicht als Fenster) läuft?
Vielen Dank1
Grüße
Mike32
Es gibt ja bei WIndows beim Desktop die Möglichkeit die Icons am Raster automatisch ausrichten zu lassen.
Mir geht es jetzt darum, diese Option ein- und wieder auszuschalten. Die Art ist mir egal (per Mausklick oder dll-Aufruf). Am liebsten wäre es mir, wenn man es jedoch per dll im Hintergrund ausführen lassen könnte. - Aber wie gesagt, da bin ich offen.
Weiß jemand, wie das geht?
Gibt es auch eine Möglichkeit vorher den "Status" hierzu abzufragen (ob dies aktiv ist)?
Thx
Grüße
Mike
Für alle Interessierten hier die (behelfsmäßige) Lösung.
Ohne Verweis bei Autoit (ich habe hierfür keinerlei Möglichkeit gefunden, dass dies irgendwie geht), kommt man nur bis zur "Ebene" VBComponents. D.h. man kann nicht auf ProcofLine zugreifen. Um dies zu umgehen habe ich mit.Export die entsprechenden Module temporär exportiert und dann mit StringinString analysiert, da die .bas-Dateien einfache Textdateien sind. Dies klappt nun hervorragend.
Und hier der Code, der teilweise auf Bugfix's Code basiert (s.o.).
Func VBAMacros_Neu()
Const $vbext_ct_ClassModule = 2
Const $vbext_ct_Document = 100
Const $vbext_ct_StdModule = 1
Const $vbext_pk_Proc = 0
Local $oProj, $oComp, $Makro, $aMakro[1] = [''], $oKompName, $oBook
$oBook = $ExcelVar.ActiveWorkbook
$oProj = $oBook.VBProject
$oMyError = ObjEvent("AutoIt.Error", "MyErrFunc")
$oComp = $oProj.VBComponents ; Wenn hier ein Fehler kommt, dann sind die Module passswortgeschützt.
$oMyError = "" ; On Error-Routine löschen
$Makro = ""
For $Komponente In $oComp
;If $Komponente.Type = $vbext_ct_ClassModule Or $Komponente.Type = $vbext_ct_Document Or $Komponente.Type = $vbext_ct_StdModule Then
If $Komponente.Type = $vbext_ct_StdModule Then ; Nur VBA-Makros
$oKompName = $Komponente.Name
$Komponente.Export(@WorkingDir & "\" & $oKompName & ".bas")
; Datei öffnen
$file = FileOpen(@WorkingDir & "\" & $oKompName & ".bas", 0)
If $file = -1 Then
MsgBox(262144 + 16, "Fehler", "Die VBA-Makros konnten nicht gelesen werden.")
Else
$line = FileRead($file)
EndIf
FileClose($file)
FileDelete(@WorkingDir & "\" & $oKompName & ".bas")
; Nun Subs auslesen
While 1
$result = StringInStr($line, "Sub ")
$result1 = StringInStr($line, "()")
If $result > 0 And $result1 > 0 Then
$Makro = $Makro & "|" & StringMid($line, $result + 4, $result1 - $result - 4)
$line=StringTrimLeft($line,$result1+1)
Else
ExitLoop
EndIf
WEnd
EndIf
Next
Return($Makro)
EndFunc ;==>VBAMacros_Neu
Func MyErrFunc() ; Fehler bei der Makroauflistung abfangen z.B., wenn PW vergeben wurde. ***
$oMyError = ""
While MsgBox(262144 + 16, "Achtung!", "Die VBA-Makros sind passwortgeschützt und können nicht aufgerufen werden!" & Chr(13) & "Bitte vorher den VBA-Schutz entfernen!") <> 1
WEnd
$temp = "-1"
EndFunc ;==>MyErrFunc
$Liste=VBAMacros_Neu()
_ExcelBookClose($ExcelVar, 0)
Do
$PID = ProcessExists("excel.exe")
If $PID Then ProcessClose($PID)
Until $PID = 0Grüße
Mike
So der Fehler wurde vermutlich eingegrenzt.
Es muss noch ein Verweis auf "Visual Basic for Applications Extensibility 5.3" gesetzt werden, damit .ProcofLine funktioniert.
Die COM-Datei heißt: Vbe6ext.olb und ist unter "c:\Programme\Gemeinsame Dateien\Microsoft Shared\VBA\VBA6" zu finden.
Weiß jemand, wie man einen Verweis setzen kann bzw. diese Datei irgendwie einbindet? Bei VB gibt es ja eine Möglichkeit dafür.
Thx
Grüße
Mike
@ Bugfix,
ich muss leider ein altes Thema/Problem ausgraben.
Ich dachte, dass der Code vom Beitrag Nr. 6 laufen würde. War mein Fehler. - Beim heutigen Testen kam folgende Fehlermeldung in Autoit
: ==> Error in expression.:
If .ProcOfLine($i, $vbext_pk_Proc) > "" Then
If .ProcOfLine($i, $vbext_pk_Proc) ^ ERROR
Ich habe ein einfache Excel-Testdatei mit drei Tabellen und einem VBA-Modul, welches drei kleine Makros enthält. Die Datei wird von Autoit geöffnet und dann kommt die obige Fehlermeldung bei Zeile 20 des Codes.
Woran könnte dies liegen?
Thx
Grüße
Mike
Hei Christoph54,
Thx für deine Antwort. Ich habe gerade festgestellt, dass sich durch das Rüberfahren der Maus über dem Fenster (Firefox) sehr wohl der Fensterinhalt ändert und zwar ändern sich die Buttons/Menüs. Dies habe ich übersehen. Ein Test mit Fensterbereichen, wo sich beim Rüberfahren nichts ändert, hat auch keine Meldung hervorgerufen.
Von daher mein Fehler. 
Grüße
Mike32
Hei,
ich habe bei einem externen Fenster, welches auch aktiv ist, für einen Bereich mit Pixelchecksum eine CRC-Prüfsumme gebildet und möchte schauen, ob sich etwas verändert. Ich habe festgestellt, dass, wenn man mit der Maus nur rüberfährt, Autoit sofort eine Änderung meldet, obwohl sich das Fensterbereich an sich nicht geändert hat.
Wie bekomme ich es hin, dass Autotit sich meldet, wenn sich nur der "echte" Fensterbereich geändert hat?
Thx
Grüße
Mike
shadow667
THX!
Das war die Lösung. 
Grüße
Mike
Hei BugFix,
thx.
Ich habe es gerade ausprobiert (geändert, gespeichert, ...) und danach SciTe neu gestartet. Man kann immer noch alle 10 vorherigen Sessions sehen. Habe ich was falsch gemacht?
Wo sind denn die letzten 10 Sessions gespeichert?
Grüße
Mike
Hie Bugfix
ich meine bei SciTe unter "Files-Save Session..." da gibt es bei mir immer eine "Auflistung" - ähnlich bei Word oder Excel.
Gibt es die bei dir nicht?
Grüße
Mike
Weiß keiner wie ich das "Speichern" der zuletzt geöffneten Dateien bei SciTe abschalten kann? 
Wäre über jeden Tipp dankbar.
Grüße
Mike
Gibt es bei SciTe irgendwo eine Einstellung, wo man die Anzahl der zuletzt geöffneten Dateien einstellen kann.
Mir geht es darum, dass die zuletzt geöffneten Dateien nicht unter dem Menupunkt "File" erscheinen.
ThX
Grüße
Mike
progandy
THx, jetzt weiß ich was #region ist.
greenhorn
Danke! Werde mal die Debugging-Funktion anschuaen.
Grüße
Mike
Andy
Thx,
tja, das mit dem Spaghetti-Code ....
Ich muss wohl etwas "umstrukturieren". Dann dürfte die Fehlersuche auch besser werden.
Der Autoit-Debugger benötigt sehr viel Zeit z.B., um ca. 200 Wert aus einem File in Variablen einzulesen. In dieser Zeit, sagt das externe Programm "auf Wiedersehen". - Und um einzelne Funktionen zu testen, muss man oft ja bestimmte Parameter oder Rahembedingungen aufwändig zur Verfügung stellen, damit man erst die Funktion testen kann. Das ist das Problem dabei.
Wegen VBA. Stimmt, aber man kann z.B. den Code bis zu einer bestimmten Stelle normal durchlaufen lassen, dann den Haltepunkt abwarten und dann im Single-Step einige Schritte langsam weitergehen und dabei dann alle Parameter beobachten und genau sehen, was exakt passiert. Dies ist an manchen schwierigen Stellen sehr wichtig. Ein Debug, der an einem "vorbeirauscht" ist dann wenig hilfreich. Auch eine Protokolldatei ist nicht optimal.
Für mich ist es auch etwas problematisch, dass es kein goto gibt. Das mit den Gosub kann man ja mit einer Function umgehen, aber goto... . Ist schon manchmal wichtig, finde ich. Dies verschachtelten Schleifen, sind nicht immer optimal.
Übrigens #region kannte ich noch nicht. Habe es auch nicht in der Hilfe gefunden. Wofür ist es überhaupt?
Nochmals Danke!
Grüße
Mike
Andy
vielen Dank für die ausführlichen Antworten. Nun wird mir einiges klar.
Autoit ist für mich schon schnell genug, was ich meinte ist, dass das Debuggen zu langsam ist. Mein Programm überprüft "externe" Programme und steuert sie an. Da es dort manchmal Probleme gibt, will man debuggen, um festzustellen wo und warum.
Ich programmiere zum Beispiel auch VBA. Dort kann man super im Einzelschritt bei voller Überwachung von Variablen, ... alles überwachen. Bei Autoit gibt es z.B. keinen Einzelschritt nur ein Debuggen/Trace an sich, wo die Ausgabe schnell angezeigt wird und das wars (hinzu kommt, dass der Code "zerstört" wird und man dann wieder suchen muss, welche Zeile was war).
Das habe ich gemeint. Autoit finde ich nämlich super. Man sollte nur massiv am Editor/Debugging nachbessern. Von daher kam meine Frage, wie man am besten die Probleme löst.
Noch zwei Fragen.
Du meintest, das schnelle Finden von UDF ist sehr wichtig. Sehe ich auch so. Wie schätzt du diesbezüglich denn Autoit z.B. zu VB oder PureBasic ein?
progandy meinte: "Das Programm wird möglichst modular geschrieben und die einzelnen Funktionen dann getestet." Meint er damit nicht einen(!) Code zu verwenden, sondern alle wichtigen Module einzeln abzuspeichern (und zu testen), dann diese mit #include einzubinden und dann mit einer "einfachen" Hauptroutine (ggf. mit Parameter) anzuspringen? Ich neige nämlich, da ich ebenfalls Basic-User der ersten Stunde bin, alles in einen Mammut-Code zu packen. 
Thx
Grüße
Mike
progandy
Thx!
Ja, so mache ich es auch. Es ist aber ziemlich nervig alles in Teile testen und dann wieder zusammenbauen, dazu kommen dann noch die Debug-Einfachheiten.
Noch eine Frage, wo ist denn der Unterschied zwischen Scriptsprache und PureBasic. Auch Autoit wird doch kompiliert. - Und der Funktionsumfang sieht mir ziemlich ähnlich aus.
ohforf
Danke für den Hinweis. Ich habe früher VB6 programmiert. Aber aus Gründen der Zukunftssicherheit und der "Veralterung" von VB6 bin ich zu Autoit gewechselt. Das neue VB finde ich mit der neuen Syntax und der neuen Philosophie ziemlich ätzend (liegt aber sicherlich an mir). Auch ist es mir ziemlich kompliziert geworden.
Grüße
Mike