Wann wird ein Callback aufgerufen

NewMori · Beiträge: 45 Erhaltene Danke: 1

Hi,
ich habe mir einen Timer geschrieben, welcher mithilfe von TimeSetEvent() in regelmäßigen abständen meine Callback-Funktion aufruft, ich übergebe im Event, den Pointer auf meine Kalsse um sie später als Sender angeben zu können. Ich habe ein paar Tests gemacht, und herrausgefunden das die Callback procedure nicht sofort aufgerufen wird (als Interrupt etc). Hier ist einfach mal der Ablauf:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

procedure Enable();
begin
...
PTimerID:=TimeSetEvent(PInterval, 0, @APITimerCallBack, Cardinal(@self), TIME_PERIODIC);
...
end;

procedure APITimerCallBack(TimerID, Msg: Uint; dwUser, dw1, dw2: DWORD); stdcall; pascal;
begin
if Assigned(TAPITimer(Pointer(dwUser)).OnTimer) then
   TAPITimer(Pointer(dwUser)).OnTimer(TAPITimer(Pointer(dwUser)));
end;

Ich würde den Timer gerne in Threads einer DLL aufrufen, ich habe aber den verdacht das zB. Schleifen nicht vom Callback unterbrochen werden, genauso wie wärend Sleep(). Wisst ihr, wie Delphi das mit Callbacks regelt, oder ob es eine Möglichkeit gibt das Callback wie ein Assembler Interrupt zu behandeln.

_________________
Es ist keine Kunst in ein Programm 20 Fehler zu schreiben. Die Kunst ist es das Programm dann noch zum laufen zu bekommen.

jaenicke · Verfasst: Sa 07.08.10 17:00

Wenn dein Hauptthread gerade Code ausführt (sei es Sleep oder etwas anderes), kannst du nicht anderen Code ausführen. Ein Thread läuft natürlich parallel, aber sobald du mit dem Hauptthread synchronisierst musst du warten bis der nicht mehr beschäftigt ist.

Eine Möglichkeit ist dabei einfach nicht Sleep zu verwenden sondern Delay. Allerdings musst du dann aufpassen, dass du bei der Parallelisierung nicht durcheinander kommst.

Generell hört sich das Konzept aber etwas ungünstig an. Windows ist nun einmal ereignisorientiert und meistens lässt sich eine Warteschleife (die ich bei Sleep vermute) auch anders umsetzen.

NewMori · Beiträge: 45 Erhaltene Danke: 1

jaenicke hat folgendes geschrieben :

Generell hört sich das Konzept aber etwas ungünstig an. Windows ist nun einmal ereignisorientiert und meistens lässt sich eine Warteschleife (die ich bei Sleep vermute) auch anders umsetzen.

Es ist keine Warteschleife, aber so ähnlich. Ich benutze einen Thread um meine Spiellogik zu berechnen, dabei wird ein Timer benutzt welcher den nächsten Befehl ausführt. Es kann aber sein, das eine Schleife erzeugt wird, welche Daten lädt etc., es gibt aber Script-basierte Events, welche zusätzlich aufgerufen werden können und immer Vorrang haben müssen. Deshalb hatte ich gehofft, dass es wie in Assembler Interrupts gibt welche denn Thread sofort anhalten und den anderen Code ausführen.

_________________
Es ist keine Kunst in ein Programm 20 Fehler zu schreiben. Die Kunst ist es das Programm dann noch zum laufen zu bekommen.

delfiphan · Beiträge: 2684 Erhaltene Danke: 32

Thread anhalten ist zwar möglich aber nicht zu empfehlen. Du weisst nicht, in welchem Zustand sich das Programm befindet.

ALF · Verfasst: Fr 13.08.10 23:12

Könntest Du nicht, mal so als Idee, wenn man in einer Schleife ist, z.B. For oder While, ne zusätzlich Procedure abfragen ob zum Beispiel ne Taste gedrückt wurde oder irgend was anderes? Wenn nicht wird die Schleife weiter ausgeführt, ansonsten wird erst das Event ausgeführt, dann weiter in der Schleife! So könntest Du auch im Thraed, zusätzlich Abfragen einbauen!
Würde zwar die Laufzeit der Schleife oder des Threads verlängern, aber durchaus machbar.
Die Frage ist nur, durch welches Ereignis müssen/werden die Scripte aufgerufen?? Wenn nicht durch Tastatur/Maus, wird es natürlich auch nichts!
Denn auch Interrupts, wenn man sie aufruft, machen nichts anderes als eine Callroutine. Ab der Zeile was anderes machen, um dann wieder dort zurück zukehren :wink:

Gruss Alf

_________________
Wenn jeder alles kann oder wüsste und keiner hätt' ne Frage mehr, omg, währe dieses Forum leer!

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme