Beiträge von Andy

Hi,
dann folgendermassen:
Erstelle einen Backbuffer, in diesen überträgst du deinen Hintergrund (also das vergrößerte Lupenbild) und anschliessend das Fadenkreuz als Bitmap. Den Backbuffer deshalb, damit das Fadenkreuz nicht flackert, sobald der Hintergrund verändert wird.
Ob du jetzt per WinApi "blittest" (das oben in deinem Scriptschnipsel Stretchblt ist nur ein aufgebohrtes Bitblt) oder per GDI-Befehlen arbeitest, bleibt sich gleich.
Den Backbuffer kannst du dir im Lupenbild sparen, wenn du die 3 Kreise und 2 Linien (also das Fadenkreuz) per GDI-Befehl direkt ins Fenster zeichnest, dann flackert auch nix.

Hi,
hehe, klassischer Fall von Mißverständnis. SeuBo und ich meinten den Mauscursor...

Soll dein "Fadenkreuz" mit in die Childgui? Oder als "Cursor" (Mausersatz) in das Auswahlfenster?
In beiden Fällen kannst du entweder das Fadenkreuz "neu" in den DC (Backbuffer) zeichnen (siehe PushTheButton), oder per _winapi_transparentblt() eine Bitmap mit dem Fadenkreuz (Hintergrundfarbe=transparent) in den DC blitten.
Alternativ kannst du auch den Mauscursor mit deinem Fadenkreuz ersetzen

Hi,
sehr feine Idee
Aber um die Bitmap-Fraktion mit ihren Bildern nicht auszuschliessen, könnte man

[autoit]

If StringRegExp(@GUI_DragFile, '(?i)\.(jpg|bmp)$') Then

[/autoit]

auch Bitmaps zulassen.

Den asm-code könntest du noch etwas tunen. Gerade um die Grauwerte in ein dword zu schreiben bietet sich statt

[autoit]

_("mov al, 0xFF") ; -\
_("shl eax, 8") ; |
_("mov al, bl") ; |
_("shl eax, 8") ; | EAX = 0xFF:BL:BL:BL
_("mov al, bl") ; |
_("shl eax, 8") ; |
_("mov al, bl") ; -/

[/autoit]

zum Beispiel an:

[autoit]

_("and ebx,0x000000FF") ;es würde auch "movzx ebx,bl" gehen, um 0x00:00:00:BL zu erhalten
_("imul eax,ebx,0x010101") ; -\EAX = 0x00:BL:BL:BL
_("or eax,0xFF000000") ; -\EAX = 0xFF:BL:BL:BL

[/autoit]

aber das ist Kleinkram^^

Was du dir aber wirklich überlegen solltest, ist die Pixel-Adressen ptrPic1 und ptrPic2 in ein Register zu packen!
Die Daten, die am häufigsten geändert werden, gehören in ein Register, das erhöht die "Schwuppdizität" enorm!
Weiterhin hast du erkannt, dass das Handling mit "Variablen" alles andere als einfach ist.
Der Zwischenspeicher auf dem Stack (Push und Pop) ist auch eine (schnelle(re)) Alternative.

Ansonsten: WEITER SO!

Hi,

Zitat von White Lion

was ist denn ein standard syntax der bei den dll-calls nicht eingehalten wurde ?

Tja, eben die Syntax!
Dazu gehört auch, die Funktion in der DLL mit den RICHTIGEN Typen aufzurufen. War es bei 32 Bit noch (meistens) schnurz, ob man "ptr", "int" oder "hwnd" oder "dword" übergeben hat, reagieren die 64-Bit-Typen da etwas empfindlicher. Was du ja selbst erkannt hast:

Zitat

ich erinnere mich, das ich damals den Dll Call angepasst hatte, was dann so aussieht:

Das liegt an der Kodierung Ansi!=UTF8

[autoit]

StringToBinary()

[/autoit]

Glücklichen Herzwunsch und alles Gute!
Hau rein und lass es richtig krachen, man ist nur einmal 25

Um das mal auszuführen^^
die Angabe von CAPTUREBLT (zusammen mit SRCCOPY) ist beim blitten zuständig für "gelayerte" Fenster(inhalte).
Der Mauscursor ist auch so ein "gelayertes" Fenster, allerdings wird er beim blitten vom System "ausgeschaltet" und ist daher nicht sichtbar.

Man muss nun "zu Fuß" den Mousecursor in ein Icon verwandeln (s. SeuBo´s Post)
Mit den Daten (Position, Höhe, Breite) des Mousecursors muss man nun einen weiteren HDC_MAUSHINTERGRUND erstellen, in den man den aktuellen "Hintergrund" (also vom HDC) des Mousecursors blittet.
Dann DrawIcon() des Mouscursors in HDC.
HDC Blitten (zusammen mit dem nun im HDC befindlichen Mousecursor)
HDC_MAUSHINTERGRUND in HDC blitten ("löscht" den Mousecursor wieder vom HDC)

Zitat

Gibts da irgendwas dafür?

Ja!

Hi,

Zitat von nuts

Ein analoger Equalizer mit "Widerständen, Spulen und Kondensatoren"?
Nee ... 2012 verwendet man DSP's!

Richtig, und Facharbeiten zum Thema liefert Google per C&P.
Was macht denn ein DSP? Interessiert mich brennend, wie der OHNE Kondensatoren, Transistoren, Verstärkern usw. zurechtkommt Der kleine schwarze Chip hat auch ein Innenleben, und das besteht nunmal aus "analogen" (passiven) Bauteilen.

Ohne Ahnung von den "Basics" ist es mit dem KnowHow bei der "HighTech" nicht weit her, das zeigt die tagtägliche Praxis.
Und der zusammengebrutzelte Haufen Bauteile in einer Marlboro-Schachtel als Gehäuse schindet (zwischen MP3-Player und einen Lautsprecher gehängt) wesentlich mehr Eindruck als ein GeC&Ptes Programm aus dem Internet für einen DSP, der als "Emulation" in Form einer App auf einem Smartphone läuft
Mal abgesehen davon, dass einem Angesichts der Brandblasen an den Fingern vom Löteisen NIEMALS jemand mit Plagiatvorwürfen kommt. Ich würde sogar bezweifeln, dass ein Lehrer auch nur einen Satz aus einer mit einer solchen "Hardware" unterstützten Seminararbeit in eine Plagiat-Suchmaschine eintippt

Zitat

Was ich derzeit spannend finde sind die unterschiedlichen Verstärkertechniken.
Class A, Class AB, Class D usw.

HIER seh ich auch keinen DSP
Aber Spass beiseite, wenn man weiss wie ein Filter/Verstärker funktioniert, und auch die dahinterliegende Mathematik sicher benutzen kann, sollte es reichlich Ideen für Anwendungen geben.

Glücklichen Herzwunsch und alles Liebe und Gute zu deinem Geburtstag!
Lass uns weiterhin an deiner "brotlosen Kunst" teilhaben!

Hi,

Zitat von To@st

oder Anregungen ein fallen würdet.

Wenn dir Hochpass, Tiefpass und Bandpass keine Böhmischen Dörfer sind und du weisst, wie man diese aus einigen Widerständen, Spulen und Kondensatoren aufbaut, und du weiterhin weisst, wie man mit einer Handvoll Transistoren einen Verstärker baut, dann ist ein "Equalizer" ein schönes Thema.
Da alles einfach zu berechnen ist, wäre eine (grafische) Umsetztung in AutoIt bestimmt reizvoll.
Die Hardware ist in weniger als einer Stunde zusammengelötet, und kostet nicht mehr als 2 Schachteln Zigaretten^^. Jedenfalls war das vor 30 Jahren so, als ich fürs Abi so ein Gerät gebaut hatte.

Hi,
Hab jetzt mal etwas rumexperimentiert, aber die wirklich einfachste Methode ist das Übergeben des (E)IP=Instruction Pointer per Parameter

Bei Verwendung von AssembleIt (oder Fasm.au3), d.h. beim Erstellen und Testen des ASM-Codes wird

[autoit]

FasmGetBasePtr($Fasm)

[/autoit]

als Parameter übergeben.

Funktioniert der ASM-Code, setzt man das

[autoit]

$_assembleit_flag=0

[/autoit]

.
Dadurch werden die Codezeilen generiert, welche den CallWinProcW-Call beinhalten.

[autoit]

Global $tCodeBuffer = DllStructCreate("byte[26]") ;reserve Memory for opcodes
DllStructSetData($tCodeBuffer, 1,"0x8B7424048B460E034612034616C30C000000B0000000000A0000") ;write opcodes into memory
$ret=DllCall("user32.dll", "ptr", "CallWindowProcW", "ptr", DllStructGetPtr($tCodeBuffer),"int",Param1,"int",0,"int",0,"int",0)

[/autoit]

Der Parameter Param1 wird nun durch

[autoit]

dllstructgetptr($tcodebuffer)

[/autoit]

ersetzt.
Da der Assembler während des Assemblierens die Adressen der Variablen berechnet, als ob ein "ORG 0" vorhanden ist, ergibt die Addition der Variablenadresse und der Startadresse des Programms die richtige Variablenadresse im Speicher, egal an welche Speicheradresse der Code geladen wird.

Beispiel:

Spoiler anzeigen

[autoit]

#include "assembleit.au3"
#include "array.au3"

[/autoit] [autoit][/autoit] [autoit]

;~ $_assembleit_flag=0
;~ $a=_assembleit("ptr", "_asm","int",FasmGetBasePtr($Fasm))
;~ ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $a = ' & $a & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
;~ exit

[/autoit] [autoit][/autoit] [autoit]

;von assembleit erstellt, wenn $_assembleit_flag=0
Global $tCodeBuffer = DllStructCreate("byte[26]") ;reserve Memory for opcodes
DllStructSetData($tCodeBuffer, 1,"0x8B7424048B460E034612034616C30C000000B0000000000A0000") ;write opcodes into memory

[/autoit] [autoit][/autoit] [autoit]

;Param1 ersetzen durch DllStructGetPtr($tcodebuffer)
$ret=DllCall("user32.dll", "ptr", "CallWindowProcW", "ptr", DllStructGetPtr($tCodeBuffer),"int",dllstructgetptr($tcodebuffer),"int",0,"int",0,"int",0)
_arraydisplay($ret)

[/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

DllCallbackFree($_DBG_)

[/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

Func _asm()
_("use32")
_("mov esi,[esp+4]")
_("mov eax,[esi+Var1]") ;00C
_("add eax,[esi+Var2]") ;0BC
_("add eax,[esi+Var3]") ;ABC
_("ret")

[/autoit] [autoit][/autoit] [autoit]

_("Var1 dd 0x00C")
_("Var2 dd 0x0B0")
_("Var3 dd 0xA00")
EndFunc ;==>_asm

[/autoit]

Hi,
"entfernen" kann man bei Grafiken nichts!
Du kannst einen bestimmten Bereich wiederherstellen, indem du die ursprüngliche Grafik zwischenspeicherst (in einem sog. "buffer") und diesen als Leinwand nimmst, um darauf zu zeichnen.
Suche mal nach "Backbuffer" hier im Forum, die Frage wurde schon gefühlte 1,2 Millionen mal gestellt^^

@K4v,
welche Windows-Version?
Habe leider diese Woche nicht mehr die Möglichkeit, anderes als XP32 zu testen.

@Marsi,
von der Geschwindigkeit her wird sich nichts ändern, im Prinzip wird das Programm in den speicher geladen und dann per call gestartet, wie bei dll´s auch.

Zitat

Wenn man jetzt DllCallAdress nutzt stattdessen, "räumt" das den Stack auch auf, oder muss man dann aufpassen, dass man ihn selbst am Ende wieder leert ?
(Ich weiß leider nicht wie man das rausbekommen kann, sonst hätte ich es schon getan)

probier doch einfach mal DllCallAddress aus:

[autoit]

#include "assembleit.au3"
#include "array.au3"
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : FasmGetBasePtr($Fasm) = ' & FasmGetBasePtr($Fasm) & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console

[/autoit][autoit][/autoit][autoit]

;~ $_assembleit_flag=0

[/autoit][autoit][/autoit][autoit]

;~ $a=_assembleit("ptr", "_asm")
;~ ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $a = ' & $a & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console

[/autoit][autoit][/autoit][autoit]

Global $tCodeBuffer = DllStructCreate("byte[7]") ;reserve Memory for opcodes
DllStructSetData($tCodeBuffer, 1,"0x8B442404C20400") ;write opcodes into memory

[/autoit][autoit][/autoit][autoit]

$ret=DllCalladdress( "ptr", DllStructGetPtr($tCodeBuffer),"int",0x64);,"int",0,"int",0,"int",0)
_arraydisplay($ret)

[/autoit][autoit][/autoit][autoit][/autoit][autoit]

DllCallbackFree($_DBG_)

[/autoit][autoit][/autoit][autoit][/autoit][autoit]

Func _asm()
_("use32")
_("mov eax,[esp+4]")
_("ret 4")
EndFunc ;==>_asm

[/autoit]

Stack muss man also selbst aufräumen^^

Hi,
K4z
das mit dem Basepointer scheint wohl Versionsabhängig zu sein...

[autoit]

#include "assembleit.au3"
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : FasmGetBasePtr($Fasm) = ' & FasmGetBasePtr($Fasm) & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console

[/autoit][autoit][/autoit][autoit]

_assembleit("ptr", "_asm")

[/autoit][autoit][/autoit][autoit]

DllCallbackFree($_DBG_)

[/autoit][autoit][/autoit][autoit][/autoit][autoit]

Func _asm()
_("use32")
_("org " & FasmGetBasePtr($Fasm))
_asmdbg_()
_("ret")
EndFunc ;==>_asm

[/autoit]

führt in der Console zu

Zitat

@@ Debug(2) : FasmGetBasePtr($Fasm) = 0x026AE014

vgl EAX-Register Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

/EDIT/
oder einfacher

[autoit]

#include "assembleit.au3"
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : FasmGetBasePtr($Fasm) = ' & FasmGetBasePtr($Fasm) & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console

[/autoit][autoit][/autoit][autoit]

$a=_assembleit("ptr", "_asm")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $a = ' & $a & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console

[/autoit][autoit][/autoit][autoit]

DllCallbackFree($_DBG_)

[/autoit][autoit][/autoit][autoit][/autoit][autoit]

Func _asm()
_("use32")
_("ret")
EndFunc ;==>_asm

[/autoit]

Hi,

Zitat

übrigens braucht man die Funktion CallWindowProc nicht mehr.
AutoIt 3.3.8 beinhaltet eine neue Funktion DllCallAddress.

uuups, danke für den Hinweis^^, man kann nun auch mehr als 4 Parameter übergeben.

K4z,
das mit dem Basepointer in ESI war eine zufällige Fundsache (XP32). Besser ist es natürlich, den BP direkt zu übergeben.
Wie wäre es, beim erstellen der Struct für den Bytecode die Adresse zu merken und direkt in den Code zu patchen?

Hi,

Zitat von Ilse

...aber die sind im ersten Satz immer noch drin. Trotz einem Pipe. Wieso?

Weil das Pipe drin ist....s. Bugfixens Post, er schrieb eindeutig

Zitat von Bugfix

Mit "[^\[\]]" hast du ein negierendes Set, d.h. du bekommst alles ausser den im Set angegebenen Zeichen.

Wieso nimmst du nicht diesen Pattern?

Hi,
ja, man kann sich mit den Regexen Stunden- Tage- und Wochenlang beschäftigen.
Allerdings frage ich mich manchmal, wieso man auch nur einen Gedanken an ein Regex verschwendet, wenn die "Standard"-Stringfunktionen das Problem in 3 Sekunden abwatschen....
Wenn ich keine [ im Text haben möchte, dann benutze ich

[autoit]

stringreplace($text,"[","")

[/autoit]

.
Ja, ggf, muss man 5 Zeilen schreiben und erreicht dasselbe Ergebnis wie ein Regex. Das dauert aber keinesfalls länger (jedenfalls bei mir, "komplizierte" Probleme teile ich in mehrer einfache auf).
Wenn man täglich Textfilter benutzt, sind Regex eine klasse Sache, unbestritten.
Aber für "pillepalle" Probleme bevorzuge ich pillepalle Lösungen.

Hi,

Zitat

Ich arbeite an einem kleinem Cloud Projekt und ich habe dazu ein kleines FTP Problem: Es kommt dauernd ein Fehler in Form von:

Das ist kein FEHLER, sondern ein Hinweis!

Zitat

$GENERIC_READ previously declared as a 'Const'

Hast du schon mal versucht rauszufinden, was das ganze auf deutsch übersetzt heissen könnte?

Da ist eine Konstante doppelt deklariert, sonst nix....
Also Zeile auskommentieren, und fertig.

Versuch mal testweise die BETA-Version (Alt+F5) zu benutzen, da werden auch andere includefiles angesprochen, hat bei mir schon bei einigen Scripten geholfen.