Beiträge von pandel

Hi ISI360,

erstmal danke für die vielen Überarbeitungen und Neuerungen. Ich hab das Gefühl, alles in allem läuft es geschmeidiger ;-)! Sehr angenehm...

Könntest du allerdings bitte mal prüfen, ob bei dir der Debugger läuft, wie erwartet? Ich bekomme zwar das Fenster und er macht und tut, zeigt aber im Editor nicht mehr an, wo er ist, keine Breakpoints usw.. Ich hab schon mit dem Fenster Infotool versucht, was herauszufinden, aber neuerdings bekomme ich das Handle für die Scintilla Komponente nicht mehr angezeigt. Hast du da was an der Integration in das Editor Tab geändert? Ich denke, da liegt irgendwo der Hund begraben, daß das Handle nicht mehr so einfach zu kriegen ist.

Außerdem ist "[CLASS:Scintilla;INSTANCE:2]" mittlerweile das untere Konsolenfenster und leider nicht der Editor. Der meldet sich im Infotool nur noch mit SysTabControl32...

Wenn ich genau weiß, was sich da getan haben könnte, pass ich das in der dbug.au3 an und poste ein Update...

EDIT: aus "[CLASS:Scintilla;INSTANCE:2]" mach "[CLASS:Scintilla;INSTANCE:1]" und es geht wieder ;-))

Lieber Gruß
Holger

Hi!

Habe die Lösung, falls es jemanden interessiert. Die Routine _Console_STARTUP muss etwas abgeändert werden:

Die Zeilen 28-34 kommen dazu, Zeile 19 geändert, dann klappts.

Liebe Grüße
Holger

ICH HABS!! JUHUUUU! Eine 2wöchige Odyssee hat ein Ende. Es lag nicht an ReadConsoleInput. Aber hier erstmal das Beispiel:

Aber jetzt kommts: der Witz der Konstante $_Console_USEWINDOW ist es, daß das Programm entweder immer eine EIGENE Konsole (false) öffnet, oder ob es, wenn am DOS Prompt gestartet, diesen direkt als Console nutzt (true). Ich hab natürlich immer auf TRUE stehen gehabt, da ich ein separates Konsolenfenster nicht gebrauchen kann in meinem Fall. Jetzt hat sich gerade beim Testen herausgestellt, daß es im separaten Konsolenfenster wunderbar funktioniert, nur nicht, wenn ich auf Weiternutzung des bereits bestehenden Konsolenfensters bestehe.

Die Routine _ConsoleStartupAtDosPrompt machte ursprünglich ein FreeConsole+AllocConsole für eine NEUE Konsole, aber nix besonderes für die alte, sondern holt sich nur STDIN und STDOUT. Lt. Microsoft sollte der STDIN per CreateFile auf CONIN$ verfügbar sein. Damit war für mich ja alles gut. Irgendwie hab ich gerade gedacht, vielleicht wäre ein AttachConsole noch ratsam, ABER ich habe gerade herausgefunden, daß ein einfaches AttachConsole bei dem bestehenden DOS Fenster eben NICHT reicht. Erste FreeConsole+AttachConsole resetten wohl STDIN und STDOUT so sauber, daß es damit funktioniert.

Wie geil! Jetzt muss die Routine nur noch den XP 32bit Test überstehen, dann ist alles im grünen Bereich.

Greenhorn, vielen Dank für deine Diskussionsbereitschaft zum Thema. Ich hätte sonst einige Sachen einfach nicht durchprobiert ;-))

BTW: Über die hohen Mauern der Assembler Programmierung bin ich nie gekommen und habe großen Respekt vor jedem, der damit was vernünftiges Zustande bekommt Spannend fand ich das aber immer...

Lieber Gruß
Holger

Aha, und in meiner wincon.h aus dem Win8 SDK (gestern runtergeladen) sieht es so aus, da is nix mit gesondertem alignment. Merkwürdigerweise finde ich in meiner wincon.h die Definition von ReadConsoleInput(A/W) überhaupt nicht???
(EDIT: Ok, gefunden, ist in consoleapi.h)

Und ich finde im Windows SDK keine wincon.inc... habe aber auch nicht Visual Studio, sondern nur das SDK installiert.

typedef struct _KEY_EVENT_RECORD {
    BOOL bKeyDown;
    WORD wRepeatCount;
    WORD wVirtualKeyCode;
    WORD wVirtualScanCode;
    union {
        WCHAR UnicodeChar;
        CHAR   AsciiChar;
    } uChar;
    DWORD dwControlKeyState;
} KEY_EVENT_RECORD, *PKEY_EVENT_RECORD;


typedef struct _INPUT_RECORD {
    WORD EventType;
    union {
        KEY_EVENT_RECORD KeyEvent;
        MOUSE_EVENT_RECORD MouseEvent;
        WINDOW_BUFFER_SIZE_RECORD WindowBufferSizeEvent;
        MENU_EVENT_RECORD MenuEvent;
        FOCUS_EVENT_RECORD FocusEvent;
    } Event;
} INPUT_RECORD, *PINPUT_RECORD;

Aber Moment, da fällt mir was auf. Inder Windows MSDN Doku dazu steht:

lpBuffer [out]


    A pointer to an array of INPUT_RECORD structures that receives the input buffer data.


    The storage for this buffer is allocated from a shared heap for the process that is 64 KB in size. The maximum size of the buffer will depend on heap usage.
nLength [in]


    The size of the array pointed to by the lpBuffer parameter, in array elements.

Sollte ich also vielleicht ein Array mit einem oder 2 Elementen definieren? Ehrlich gesagt weiß ich dann aber nicht mehr, wie man das schreiben würde...

Zitat von Greenhorn

Wäre schön, wenn Du ein Beispielskript zur Verfügung stellen könntest.

Die betroffene Routine ist in dem Post über deinem ;-))

Das mit dem Handle ist nicht so das Problem:

$hConsoleIn = _WinAPI_CreateFile("CONIN$", 3, 6, 7)

Wichtig ist wirklich 3,6,7!!!! Das geht unter x86 und x64.

Problem ist, daß ReadConsoleInput IMMER blockt! Ich machs mal ganz einfach (ist ne Routine von prog@andy, aber ordentlich umgebaut):

Global Const $tagKEYEVENTREC = "bool bKeyDown;word wRepeatCount; word wVirtualKeyCode; word wVirtualScanCode; char UnicodeChar; char pad; dword dwKontrolKeyState;"
Global Const $tagINPUT_RECORD = "align 4;word evtyp;struct;" & $tagKEYEVENTREC & "endstruct;"

Func _ConsoleGetChar()
Local $ret, $Key_Event = False, $HWND
Local $keyev[6] ; key event array
Local $tInp = DllStructCreate($tagINPUT_RECORD)

; set console as active window
$HWND = DllCall("kernel32.dll", "hwnd", "GetConsoleWindow")
WinActivate($HWND[0])

DllCall("Kernel32.dll", "bool", "FlushConsoleInputBuffer", "handle", $GLOBAL_hConsoleIn)
Do
$ret = DllCall("Kernel32.dll", "dword", "WaitForSingleObject", "handle", $hConsoleIn, "dword", -1)
If @error Then Return SetError(1, 0, 0)
If $ret[0] = -1 Then Return SetError(2, 0, 0)
Local $rce = DllCall("kernel32.dll", "bool", "ReadConsoleInput", "handle", $hConsoleIn, "ptr", DllStructGetPtr($tInp), "dword", 1, "dword*", 0)
$Key_Event = DllStructGetData($tInp, 'evtyp') = 1 ; keyboard event
;$keyev[0] = DllStructGetData($tInp, 'bkeyDown')
;$keyev[1] = DllStructGetData($tInp, 'wRepeatCount')
;$keyev[2] = '0x' & Hex(DllStructGetData($tInp, 'wVirtualKeyCode'),4)
;$keyev[3] = '0x' & Hex(DllStructGetData($tInp, 'wVirtualScanCode'),4)
$keyev[4] = DllStructGetData($tInp, 'UnicodeChar')
;$keyev[5] = '0x' & Hex(DllStructGetData($tInp, 'dwKontrolKeyState'),4)
Until $Key_Event And StringIsAlpha($keyev[4])
DllCall("Kernel32.dll", "bool", "FlushConsoleInputBuffer", "handle", $hConsoleIn)
Return $keyev[4]
EndFunc ;==>_Console_Pause

Das geht hervorragend unter XP und sogar Win7 x86, eben nur nicht unter Win8 x64...

Greenhorn
Nein, tut es leider nicht. Ich hab schon die dollsten alignment Varianten durch. In der wincon.h, wo der Tag definiert ist, wird KEY_EVENT_RECORD einfach nur als PACKED definiert, INPUT_RECORD selber dagegen ist nicht packed! Ich krieg nicht raus, was genau, also ob align 2 oder 4 oder was auch immer. In den Microsoft Unterlagen steht, daß Standardalignment 8 ist. Daher hab ich gedacht, ich probier auch mal folgendes:

Global Const $tagKEYEVENTREC = "align 4; bool bKeyDown;word wRepeatCount; word wVirtualKeyCode; word wVirtualScanCode; char UnicodeChar; char pad; dword dwKontrolKeyState;"
Global Const $tagINPUT_RECORD = "align 8;word evtyp;struct;" & $tagKEYEVENTREC & "endstruct;"

Aber das tut's auch nicht.
Dieses schei*** ReadConsoleInput braucht immer genau 1x ENTER, erst dann nimmt es den Buchstaben an und kehrt auch brav sofort zurück. Als müßte ich mit dem ENTER erst die Consoleneingabe aktivieren, oder so'n Quatsch!

DLL's unter C oder ner anderen Sprache hab ich noch nicht gebaut, sonst hätte ich das schon längst über ne eigene DLL geregelt

Nur so, falls noch wer mitliest:

ich glaube mittlerweile, daß es am byte alignment liegt, leider komm ich grad nicht an meine Win8 Kiste... das ist eigentlich ein packed struct. Ich wühl mich mal durchs Windows SDK, um herauszufinden, was da wie gepacked ist... übrigens dazu ein super Artikel im QB64 Forum, witzigerweise genau mit der ReadConsoleInput Funktion beschrieben ;-):

http://www.qb64.net/forum/index.ph…g47094#msg47094

Nur die Datentypen in QB64 sind da etwas unterscheidlich lang, aber zum Verständnis macht das ja nix aus!

Lieber Gruß
Holger

Hallo zusammen!

Ich hab jetzt sämtliche Vorschläge und Ideen durch und bin mit meinem Latein am Ende. Mein Problem ist, daß unter Win8 64bit beim Call auf ReadConsoleInput diese Funktion einfach blockt, was sie baer nicht tun dürfte. Sie müßte sofort mit einem Signal zurück kommen, tut sie aber nicht.

Jetzt weiß ich auch nicht mehr weiter...

Lieber Gruß
Holger

Danke, ich probier's auf jeden Fall aus

Hey BugFix , danke für den Hinweis! Muss aber, weil ich das noch nie verwendet habe, der Sicherheit halber nochmal nachfragen, ob ich's richtig verstanden habe. Es sind ja eigentlich zwei structs ineinander:

So?

Global Const $tagKEYEVENTREC = "struct;bool bKeyDown;word wRepeatCount; word wVirtualKeyCode; word wVirtualScanCode; wchar UnicodeChar; dword dwKontrolKeyState;endstruct;"
Global Const $tagINPUT_RECORD = "struct;long evtyp;" & $tagKEYEVENTREC & "endstruct;"

EDIT: ich glaub, eher so, oder?

Global Const $tagKEYEVENTREC = "struct;bool bKeyDown;word wRepeatCount; word wVirtualKeyCode; word wVirtualScanCode; wchar UnicodeChar; dword dwKontrolKeyState;endstruct;"
Global Const $tagINPUT_RECORD = "long evtyp;" & $tagKEYEVENTREC

Außerdem hab ich gerade progandy's "Nested DLLStructs" gefunden Ich denke, das kann ich hier verwenden.

Hallo!

Ich habe mir für ReadConsoleInput folgende Konstruktion gebastelt (ich führe nur die entscheidenden Zeilen auf und lassen den ganzen Funktions-Schleifen-zipzap weg):

Global Const $tagKEYEVENTREC = "bool bKeyDown;word wRepeatCount; word wVirtualKeyCode; word wVirtualScanCode; wchar UnicodeChar; dword dwKontrolKeyState"
Global Const $tagINPUT_RECORD = "long evtyp;" & $tagKEYEVENTREC

Local $tInp = DllStructCreate($tagINPUT_RECORD)
Local $result = DllCall("kernel32.dll", "bool", "ReadConsoleInput", "handle", $GLOBAL_hConsoleIn, "ptr", DllStructGetPtr($tInp), "dword", 1, "dword*", 0)
$Key_Event = DllStructGetData($tInp, 'evtyp')
If $Key_Event = 1 then $key = DllStructGetData($tInp, 'UnicodeChar')

Zugehörige Doku im MSDN:
ReadConsoleInput
INPUT_RECORD
KEY_EVENT_RECORD

Das funktioniert wunderbar (da ich auch nur KEY_EVENT_RECORDs auswerten muss) unter allem, was ich bis jetzt an 32 bit OS unter den Fingern hatte. Bei Win 8 64 bit allerdings passiert nur Müll. Ich kenne mich leider mit den Struct-Datentypen nicht so gut aus, um wirklich beurteilen zu können, welcher Typ im Struct möglicherweise Probleme macht.

Hier gibt's aber soviele wirklich super fitte Leute und ich hoffe, dass jemand kann mir da einen Tipp geben.

Schonmal danke im Vorhinein fürs Ansehen...

Lieber Gruß
Holger

Hi!

Ich habe eine Frage. Die UDF als solches ist super und speziell die Funktion _Console_Pause funktioniert unter XP tadellos. Aber unter Win 8 64bit kann man in die Tasten hauen so viel man will, es passiert rein gar nichts.

progandy, falls du das liest, könntest du versuchen herauszufinden, was da verkehrt läuft?

Ich habe fast die gleichen Funktionen in einer eigenen Routine gehabt und gedacht, ich wäre einfach nur zu doof, das zu programmieren. Da du unzweifelhaft extrem fit bist, hab ich geglaubt, deine Routine wird's schon tun, aber sie zeigt genau das gleiche Verhalten. Microsofts MSDN liefert nichts brauchbares und auch Google schweigt sich dazu aus.

Aber vielleicht fällt ja irgendwem was dazu sein, dann bitte immer her mit den Ideen! Ich habs schon mit anderen Funktionen wie ReadConsole, Handle öffnen über CreateFile mit CONIN$ und SetConsoleMode versucht, etc., aber nichts hilft... Alle Funktionen blocken irgendwie. So langsam verzweifel ich daran!

Ich benötige eine Funktion, die genau EINEN Tastendruck nimmt, zurückkehrt und die gedrückte Taste als Rückgabewert hat UND die von XP bis Win8 funktioniert und leider liegt genau da das Problem.

Lieber Gruss
Holger

Zitat von ISI360

Und wegen den Versionsnummern: Sehe ich das richtig das da beim Kompilieren etwas in die Hauptdatei geschrieben/verändert wird und daher der Inhalt neu geladen werden soll? (Kann es aktuell leider nicht testen.... -.-)

Zu dem Namen habe ich leider keine gute Idee... die von chesstiger ist schon ganz ok. Das läßt sich irgendwie nur recht holprig übersetzen...

Aber was die Versionierung anbelangt, ja der macht aus
#AutoIt3Wrapper_Res_Fileversion=1.0.0.1
nach dem Kompilieren
#AutoIt3Wrapper_Res_Fileversion=1.0.0.2
und schreibt das in die Hauptdatei.

Ich war ja schon so bauernschlau und hatte den Teil in eine include ausgelagert, aber das checkt der Compiler nicht

EDIT: im Grunde könnte das doch vielleicht so ähnlich laufen wie bei Tools\Tidy Source, oder?

Hallo ISI360,

alles fit bei Dir? Hoffe doch ;-))...

Ich hab eine Frage: wenn man folgende Optionen benutzt

#AutoIt3Wrapper_Res_Fileversion=1.0.0.1
#AutoIt3Wrapper_Res_FileVersion_AutoIncrement=y

und kompiliert, dann wird leider, sofern die Hauptdatei des Projekts geöffnet ist, die imkrementierte Versionsnummer nicht in den Code geholt. D. h. man muss die Nummer aus dem Konsolenfenster manuelle übertragen. Es wäre schön, wenn du danach entweder das Skript nochmal neu laden würdest, oder, was schneller aber aufwändiger wäre, die neue Versionsnummer aus der Konsole holst und dann im Quellcode abänderst. Ist eigentlich nur lästig

Lieber Gruß
Holger

Hey ISI360,

schau mal hier http://www.autoitscript.com/forum/topic/62…ions-visualiser . Das wär doch was fürs 'Tools' Menü, oder?

Lieber Gruß
Holger

+1 Genau. Meld dich drüben an und wir reden drüber. Tipp: mittlerweile gibt's für die Grundfunktionen eine Hilfe. Ein Tutorial ist noch in Planung, komme ich aber gerade nicht zu...

Du hast recht! Ich bastel mir da was mit den Makros zusammen, hab ich gar nicht drüber nachgedacht

Hallo ISI360,

hab da noch ne Frage: wäre es möglich, daß du für das Erstellen des Release Ordners eine Option schaffst, mit der man gezielt vorhandene Dateien und Unterverzeichnisse im Projektordner ausschließen kann? Ich schiebe mein aktuelles Projekt bspw. in ein SVN Repo. Dein Release Mechanismus kopiert mir beim Kompilieren (nur EXE, ohne den Quellcode einzuschließen) nun sämtliche zusätzlich vorhandenen Ordner immer mit, aber ich brauche die im Release nicht alle; bspw. mein .svn Ordner, oder Ordner mit Hilfsdokus, etc.

Lieber Gruß
Holger

Hey chip!

Danke für den netten Verweis ;-))!!

Gruß
Holger

Tja, und kaum hatte ich's geschrieben, hat es mich auch nicht losgelassen... Is feddich!

Ich habe die dbug.au3 so abgeändert, daß du im ISN selber gar nichts mehr ändern mußt. Die dbug.au3 findet die Ordner, die Konfig und die Sprachdateien ganz von alleine. Das einzige, was du also machen musst, ist die dbug.au3 zu ersetzen und die beiden ergänzenden Sprachdateien hier ausm Anhang nehmen und an deine originalen Sprachdateien dranhauen. Ich hab ab str821 losgelegt, weil gepennt Also sach nix... Funzt aber sonst gut. Ich find diesen Debugger sooo geil Wußtest Du, daß man die Debugger-internen Variablen selber debuggen kann ;-)? Starte mal ein x-beliebiges Projekt mit Debugger, gib im Kommandofenster einfach nur den Variablennamen $DBGConfigfile ein und drück Ctrl-Enter... Ach so, mir ist noch was aufgefallen: wenn man einen bedingten Ausdruck für einen Haltepunkt eingibt (Eingabefeld am oberen Rand rechts) darf man kein " benutzen, sondern nur '. Also $foo="bar" geht nicht, aber $foo='bar' super! Nur so als Tipp, falls mal wer fragt...

Und bzgl. des Editor Projekts im englischen Forum:
Das find ich recht gut, nur für meine belange etwas zu fett. Ich finde diese hier ganz schön, weil es die Basisfunktionen hat und damit ist erstmal gut. Ausbauen kann ich das ja immer noch. Wichtig ist mir halt der Lexer. Ich brauche es für eine Skriptsprache, die nicht von den Standardlexern unterstützt wird und da dachte ich, wo ich schon einmal dabei bin... ;-)) Das mit dem Folding kann ich mir leider auch sonst nirgendwo abschauen, weil es normalerweise ja intern in den Lexern geregelt wird. Das hab ich exemplarisch für AutoIT Skripte zwar gelesen und verstanden, aber die Umsetzung für meinen Lexer in AutoIt selber muss da noch etwas reifen...

Hi ISI360,

nur zur Info: es wird mit der Übersetzung noch ein wenig dauern, da ich momentan noch ein anderes Projekt an der Backe habe. Schreibe gerade an einem Editor mit Scintilla, ABER der Lexer mit Highlighting, Folding, etc. wird komplett in AutoIt geschrieben Läuft auch schon echt gut, nur am Folding beiß ich mir gerade noch etwas die Zähne aus ;-)))

Übrigens hat mir da die Debug Funktion beim Umsetzen des Highlightings schon sowas von geholfen, einfach Oberklasse :)!

Gruß
Holger