Hook.dll und programm liefern kein ergebnis

[DGL-luke]

aaalso...

wie erwartet:

aktiviere ich ein anderes fenster, funktioniert der hook schon nicht mehr. er ist im moment also auf deinen prozess beschränkt, in dem dein fensterhandle bekannt ist.

Mehrere Tastendrücke schickt er, weil er für das drücken der taste, während die taste gedrückt ist, und vor und nach dem loslassen jeweils einmal die hookproc aufruft. oder so ähnlich.

Ich hab aus der Hookproc mal folgendes gemacht:

Delphi-Quellcode:

function KeyboardHookProc(nCode: Integer; wParam: WPARAM; lParam: LPARAM):
LRESULT; stdcall;
begin
//es ist ebenfalls möglich die Bearbeitung an eine Bedingung zu knüpfen
//it's possible to call CallNextHookEx conditional only.
  Result := CallNextHookEx(HookHandle, nCode, wParam, lParam);
  case nCode < 0 of
    TRUE: exit; //wenn code kleiner 0 wird nix gemacht
                //if code smaller 0 nothing has to be done
    FALSE:
      begin
       if (lparam shr 30) = 0 then
         sendmessage(WindowHandle, WM_KeyLogMessage,wparam,lparam);
//Hier kann jetzt alles bearbeitet werden
//Here one can work with the parameters
      end;
  end;
end;

Damit kommen nur noch zwei an.
Deine kleine Hausaufgabe: Sag mir, warum das so ist.
Tipp: per "shr 30" schiebe ich alle bits außer 30 und 31 aus dem integer, d.h. nur 30 und 31 bleiben als MSB oder LSB übrig (wie endian das ganze ist, will ich jetzt nicht nachlesen)

[Olli]

Argh, ich muß das Hook-Tut wirklich dringend überarbeiten. Gibt's hier jemanden der sich ein paar Lorbeeren als Coautor verdienen will?

[SirThornberry]

ich finde du solltest das tutorial NICHT überarbeiten. Denn ansonsten wird wirklich nur kopiert und niemand bemüht sich in die Materie einzusteigen.
So wie es jetzt ist geht es im Ansatz und wer mehr machen will muss sich genauer damit auseinander setzen um es ordentlich hinn zu bekommen.
Wenn du ein fertiges Copy-Paste-Tutorial wird einfach nur kopiert (ohne zu verstehen) und der quelltext drum herum hat dann in etwa das gleiche Niveau. Resulatat wäre das ständig Programme wegen Script-Kiddi-Hooks abstürzen..

[stoxx]

Zitat von Chaosente:

Tut mir leid ich versteh nur bahnhof! kann mir jemand erklären was das heißen soll?

es bedeutet einfach, dass Deine Variable WindowHandle keine globale Variable darstellt, wie Du fälschlicherweise angenommen hast.
Du brauchst also einen zentralen Ort, wo Du die Variable abspeichern kannst.
Es müssen Dich also genau dieselben Fragen beschäftigen, als wenn zwei programme daten austauschen wollen.
Grund ist eben, die DLL wird von jedem Process geladen. Es existieren also genau so viele Variablen, wie auch die DLL geladen wurde...

Delphi-Quellcode:

var 
  HookHandle: Cardinal = 0; 
  WindowHandle: Cardinal = 0;

http://assarbad.net/stuff/tutorials/...k_tutorial.pdf

da steht eigentlich alles drin ..

[DGL-luke]

Zitat von Olli:

Argh, ich muß das Hook-Tut wirklich dringend überarbeiten. Gibt's hier jemanden der sich ein paar Lorbeeren als Coautor verdienen will?

*meld*

Reicht es, wenn ich schon meinen eigenen Keyboard-LL-Hook geschrieben hab (Ich bin sogar irgendwie an meinen Monitorprozess zurückgekommen. Muss ich mal schauen, ob ich die alten Sourcen noch find)?

@SirT: Die Überarbeitung von Tutorials ist nie schlecht.

[Chaosente]

Hab ich das richtig verstanden, das wenn ich in der dll, die daten einfach in eine datei schreiben würde sich keine probleme ergeben würde, aber wenn ich sie an mein fenster schicken möchte den umweg mit MMF gehen muss?

[Olli]

Zitat von Chaosente:

Hab ich das richtig verstanden, das wenn ich in der dll, die daten einfach in eine datei schreiben würde sich keine probleme ergeben würde, aber wenn ich sie an mein fenster schicken möchte den umweg mit MMF gehen muss?

Kommt auf die Daten an.

Also, wenn du in der Hook/Callbackfunktion bist, laeuft dein Code ja im Kontext eines anderen Prozesses. Du musst also die Prozessgrenzen ueberwinden. Das geht zwar mit Nachrichten, aber die zu verschickenden Daten sind dann normalerweise auf 2x 32bit beschraenkt. Um also mehr Daten zu verschicken, bietet sich eindeutig MMF an.



@Luke: Wie kennst du dich mit LaTeX aus? Wenn garnicht, dann muessten wir die Zusammenarbeit einfach im unformatierten Textformat machen. Ich will sicherstellen, dass es PDF-Dateien mit Vektorgrafiken sind und als Grundlage zum Hooktut muss auch das DLL-Tut nochmal aufgefrischt werden. Bist du dabei? Code wuerde ich ohnehin sowohl fuer C als auch fuer C++ und eben Delphi schreiben wollen. Bei Delphi waerst du bis Oktober auf dich gestellt, da ich im Moment keine Installation und eben auch kein Installationsmedium habe und TurboDelphi kommt mir nicht auf die Platte.

[stoxx]

Zitat von Chaosente:

Hab ich das richtig verstanden, das wenn ich in der dll, die daten einfach in eine datei schreiben würde sich keine probleme ergeben würde, aber wenn ich sie an mein fenster schicken möchte den umweg mit MMF gehen muss?

ja das ist richtig, in eine Datei (Text) könntest Du Deine zu loggenden Daten hineinschreiben.
Du könntest Dir auch Dein Handle in eine Text Datei speichern, theoretisch. und dann dort auslesen, damit Du weißt, wo Du mit Sendmessage Deine Daten hinschicken musst.
Würde aber niemand machen

Memory-Mapped-Files würden Dir da aber auch noch nix nützen, (Sind ja Files) in den Memory gemappte Files eben..
aber Microsoft bietet Dir mit der Option

MemFile := CreateFileMapping($FFFFFFFF.nil ...) an, Deine Daten auch prozeß-übergreifend gemeinsam zu nutzen, womit der Datenbereich in der Auslagerungsdatei von Windows angelegt wird (bzw. irgendwo im Cache vorher

Somit können die "vielen" Dll's von jedem Programm (Prozeß), was gehookt wird, auch Dein WindowHandle wieder lesen ...
und die DLL kann dann mit dem richtigen Handle eine Sendmessage verschicken

Mit MMF könntest Du wiederum eine noch größer Datenstruktur (Record) anlegen, und diese mit einer Funktion in der DLL "GetData(var Data: TMyData)" auslesen. Und mit Sendmessage teilst Du Deinem Programm nur mit, dass jetzt neue Daten da sind ...