Entwickler-Ecke

Grafische Benutzeroberflächen (VCL & FireMonkey) - Problem mit threads


TheHolyMan - Mo 13.12.04 22:29
Titel: Problem mit threads
Also folgendes

ich habe eine Thread der die aufgabe hat über eine spezielle komponente Daten über die serielle Schnitstelle zu senden und zu empfangen

der thred gehört einer "form" damit ich auf die Ereignisse reagieren kann.

nun ist folgendes Problem aufgetreten

der thread muss manchmal eine funktion ausführen die über 10 sekunden nur warten muss .. in dieser Zeit werden aber keine ereignissse mehr ausgeführt.

im hauptprozess könnte man das mit application.processmessages lösen .. aber in einem thread?


herzi - Di 14.12.04 12:03

Friert das Formular dann ein ?

Dafür gibts TAntiFreeze!


TheHolyMan - Di 14.12.04 15:31

nein allgemein ... sobald der thread in einer warteschleife ist werden keine ereignisse mehr aufgerufen!!


Delete - Di 14.12.04 15:36

Kann nicht sein. Warum sollten keine Ereignisse für das Hauptfesnter aufgerufen werden, wenn sich der zweite Thread in einer Warteschleife befindet? Was ist das überhaupt und wie sieht sie aus?


TheHolyMan - Di 14.12.04 15:54

nein .. also alles spielt sich in einem thread ab ...

der thread reagiert auch auf ereignisse ... aber wenn er in einer warteschleife hängt werden die ereignisse für den thread nicht mehr aufgerufen


Delete - Di 14.12.04 17:11

Irgendwie logisch oder? Warum sollte sich ein separater Thread anders verhalten, wie der Hauptthread von deinem Fenster? Auch ein separater Thread kann keinen Code an zwei Stellen gelichzeitig ausführen (Auf Ereignisse reagieren und in deiner Warteschleife hängen.)

Was soll das überhaupt mit der Warteschleife in dem Thread? Auf was wird gewartet? Und warum wird gewartet? ich fürchte du hast ein ziemliches Design Problem.

Windows bietet dir die Möglichkeit mit Ereignissen zu arbeiten, die Zeiten des Pollings in einer Schleife sind eigentlich vorbei.


TheHolyMan - Do 16.12.04 00:44


Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
er verhält sich eben nicht gleich ....

while a < 1000 do begin 
  ..  
  .. // polling der einzelnen com-geräte (status abfragen und auf antwort warten)
  Application.processMessages
end;


Procedure tmr1.OnTimer()
begin
  ...
  ...
end;


wenn sich dieser code allein in einem hauptprogramm befinden funktioniert alles ...
durch Application.processMessages wird das Timerevent richtig aufgerufen.

befindet sich das jedoch in einem thread .. dann wird das ereignis nicht aufgerufen.


Zitat:
ich fürchte du hast ein ziemliches Design Problem.

isch muss nur eine änderung vornehmen am programm ... *argh*

Moderiert von user profile iconTino: Code- durch Delphi-Tags ersetzt.


TheHolyMan - Do 23.12.04 11:11

weiss keiner weiter?


.Chef - Do 23.12.04 11:19

Du hast wirklich ein Designproblem. Der Sinn von dem Thread ist ja, dass man pollen kann, ohne dass das Hauptprogramm einfriert. Im selben(!) Thread während des Pollens noch etwas anderes parallel zu machen widerspricht der Logik seines Daseins. Wenn du also mehr Aktivitäten brauchst, nimm mehrere Threads!


Lossy eX - Do 23.12.04 11:37

Also ich denke auch mal, dass du ein Designproblem hast. Normal würde ich die Fenster und die Arbeit (Comschnittstelle) in seperate Threads packen. Die Fenster entweder im VCL-Thread oder in einem Thread, der nur für das Fenster zuständig ist. Und die kompletten COM Sachen alle in einem eigenen Thread. Wenn dieser dann blockiert reagieren die anderen Threads noch wie gewohnt. Dann brauchst du auch nicht so etwas wie Application.ProcessMessages machen. Was ich persönlich für die schlechteste Alternative halte, da es auch Schwierigkeiten mit sich bringen kann.