Signalslots

Zur Vorstellung von Komponenten und Units für Lazarus
schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

@Christian

Wieder das gleiche Problem. Ich kann auf jedes Formular das an dem Timesignal teilhaben soll einen TTimer installieren. Bei Delphi ist bei 16 TTimer'n abtuten. Also war die logische Idee ein TTime-Objekt zu verwenden um die nötigen Ticks (alle 1 sec oder 10 sec oder 30sec oder alle 1 min) in das System zu befördern.

Damit das aber nun bei den beteiilgten Objekten auch ankommt mußte ein SignalHandler her der das eben auch an Objkete verteilt, die eben bei Delphi nicht im am Messagehandling teilnehmen können, einfach weil das Vaterobjekt nicht daran teilnimmt.

Wenn die das bei FPC geändert haben sollten würde mich das freuen, dann kann ich mir die "Klimmzüge" am Brotkasten schenken. Nur wage ich das zu bezweifeln, wenn sie weitgehend der Philosphie von Delphi gefolgt sind wird das nicht der Fall sein. Dann werden auch weiterhin alle Objekte, die direkt von TObject abstammen, nicht am Messagesystem teilnehmen und deswegen auch Signal nicht empfangen können.

Mein SignalHandler löst genau das Probelm und läßt alle Objekte zu, die zumindest von TObject abstammen. Sie dürfen sich an dem System beteiligen indem sie einfach nur das Object SignalHandler kennen. Sie können also auch Daten übertragen, das setzt natürlich voraus, das der Empfänger weiß, das auf Grund des Signals eine bestimmte Datenstruktur übertragen wird.

Genau betrachtet sollte nur noch so programmiert werden und der Signalhandler der Kern jedes Programmes sein.

Und nochmals, TTimeTicker ist ein Knecht. Es ist nicht das Kernelemt der Kiste. Bei dieser Implementierung kann jedes Objekt gleichzeitig Sender und Empfänger sein. Das geht soweit, das jedes Objekt sich aus dem System auch zur Laufzeit wieder aushängen oder einhängen kann, indem es einfach den SignalSlot registriert oder wieder deregistriert.

Der SignalHandler für sich alleine genommen könnte also schon ein Thread sein und würde trotzdem arbeiten.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Liest du eigentlich manchmal was ich schreibe oder nur immer den ersten Satz. Soweit ich weiss gibts diese Beschränkung bei Delphi seit Delphi 4 nicht mehr und bei FPC/Lazarus hats die nie gegeben.

Deine Komponente löst also ein Problem das es seit 10 Jahren nicht mehr gibt.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Beitrag von mschnell »

schnullerbacke hat geschrieben:Dazu mußt du:

Application.OnIdle

den Signalverteiler einhängen. Damit arbeitet der immer nur während der Idle-Time.



Was ist denn der "Signalverteiler" eine solche Funktion finde ich in TAppSignalHandler nicht.

-Michael

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Lol, SendSignal nimmt an und verteilt. Das sind die Sachen die man noch überarbeiten kann. Signaverteiler an OnIdle binden und SendSignal so ändern , das es ne Queue füttert.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

@Christian

Ich hab hier ein Delphi 7 enterprise. Das hat das Problem ganz massiv. Das einzige wo ich erlebt habe das es dieses Problem nicht gibt war Turbo-Pascal für Windows 6.0. Da kämen deine 10 Jahre hin. Aber das ist auch wurscht, mein SignalHandler macht es nebenbei möglich, die Slots zur Laufzeit ein- und auszuhängen. Das hat auch seine Vorteile.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Beitrag von mschnell »

schnullerbacke hat geschrieben:Lol, SendSignal nimmt an und verteilt. Das sind die Sachen die man noch überarbeiten kann. Signaverteiler an OnIdle binden und SendSignal so ändern , das es ne Queue füttert.


Ich soll also SendSignal an OnIdle binden ????

SendSignal hat einen Parameter. Ich kann es also nicht einfach in OnIdle aufrufen, wenn ich den nicht kenne.

Was soll ich also machen ?

(Ganz ohne Anleitung ist das ganz schön schwierig.)

-Michael

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Umbauen. SendSignal eventuell umbennen in CollectSignal und damit eine TList füllen aus den eingehenden Signalen bauen. Dann eine Prozedur SendSignal bauen die sich OnIdle binden läßt und dann die Liste der anstehenden Signale abarbeitet.

Zunächstmal scheinst du das aber jetzt zum Laufen zu haben. Mit dem Ding kann man ne Menge nette Sachen machen. Wie z.B. regelmäßigen Refresh einer TCP-Verbindung um den Timeout vom Router auszuhebeln. Oder eingehende Connect-Anforderungen vom TCP-Server in einer Liste anzeigen usw.. Der Vorteil ist halt, das dafür nur SignalHandler.pas in der jweiligen Quelldatei geladen sein muß. Dann kannst du bei jedem beliebigen Objekt sowohl ein Signal produzieren wie auch über einen SignalSlot ein Signal empfangen.

Die Feinarbeit sollten wir vielleicht investieren und daraus einen Thread machen.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Antworten