Lazarsprogramm für Linux ohne QT etc

[mschnell]

Ich glaube nicht, dass Indy einen Timer benötigt.
Trotzdem würde ich Synapse empfehlen. Das braucht bestimmt keinen.
http://synapse.ararat.cz/" onclick="window.open(this.href);return false;

Du hast recht. in allen 180 .pas Source-Dateien von Indy kommt "TTimer" nur zweimal in Kommentaren vor.

Ich glaube aber nicht, dass Timer aber das einzige ist, was nicht so ohne weiteres ohne GTK geht. Indy verwendet z.B. TThread.Synchronize. Das wird bei Windows mit Windows-Messages an den Main-Thread gemacht. Die funktionieren ebenfalls nicht bei einem "Programm" (statt "Anwendung"). Soweit ich weiß, funktioniert TThread.Synchronize in Free-Pascal auf Linux noch überhaupt nicht. Ich weiß nicht, ob Lazarus dafür eine funktionsfähige Implementierung hat (Lazarus/Linux muss ich erst noch installieren).

Die Lösung ist sicherlich, dass ich mir eine eigene "TApplication" bauen muss, die Messages empfangen kann, um dadurch dem Mainstream die Fähigkeit beizubringen. Wie ich das dann mit dem Rest der Lazarus/Free-Pascal Library verknüpfe, damit Indy und Genossen es verwenden können muss ich noch herausfinden.

Danke für den Tip, Synapse schaue ich mir an.

Gruß,
-Michael

[theo]

Du willst doch eine nicht visuelles Programm bauen, oder?

Dann vergiss doch mal all diese LCL/VCL Sachen.
Synchronize ist nur für die Synchronisation mit dem Main Thread bei einer LCL/VCL Anwendung.
In nicht visuellen Programmen reicht eine Criticalsection oder sowas.
Ich habe schon ein einige Konsolen Anwendungen und 3 Windows Services die in Betrieb sind gebastelt. Aber einen Timer habe ich dazu auch noch nie gebraucht.
Du musst ja sowieso selber in einen Main-Loop gehen. Von da aus kannst du doch bei Bedarf Threads starten oder sonstwas auslösen.
Das Zauberwort im Main Loop heisst: Sleep()
Auch Synapse braucht keine LCL, Synchronize, Timer....

Ich glaube du machst dir zuviele Sorgen..

[Christian]

Und was wollt ihr immer alle mit indy in einem visuellen programm kann ich es ja noch ansatzweise verstehen das man nicht visuele komponenten haben will aber in nem schlanken konsolenprogramm mit diesem ugly riesigen indy rumzuhantieren find ich blöd

[monta]

Und was wollt ihr immer alle mit indy in einem visuellen programm kann ich es ja noch ansatzweise verstehen das man nicht visuele komponenten haben will aber in nem schlanken konsolenprogramm mit diesem ugly riesigen indy rumzuhantieren find ich blöd

Naja, jedem das seine
Ist halt auch oft ne Gewöhnungssache, wenn mans von Delphi her schon x-mal eingesetzt hat, bleibt man halt oft dabei.

[mschnell]

Du willst doch eine nicht visuelles Programm bauen, oder?

Dann vergiss doch mal all diese LCL/VCL Sachen.

Ich glaube du machst dir zuviele Sorgen..

Tja leider ist das in diesem Fall nicht so einfach.

Wie (vermutlich) gesagt, soll ein funktionierendes Delphi-Programm portiert werden (das Kollegen von mir gemacht haben und weiterhin betreuen). Dabei muss der Sourcecode kompatibel bleiben, so dass sich das ganze mit Delphi (läuft dann mit GUI auf Windows-PC) und mit Lazarus/Free Pascal (läuft dann ohne GUI auf ARM/Linux) übersetzen lässt. Die fehlende GUI wird dann durch Units ersetzt, die die Funktionalität "fake"-en. Die Kollegen können dann weiter mit Delphi entwickeln und die GUI als Testumgebung verwenden.

Somit brauche ich TThread.Synchronize und Messages auf jeden Fall.

Außerdem ist es durchaus sehr praktisch, wenn man einen "Mainthread" hat und darin die nicht zeitkritschen Funktionen des Programms serialisiert. Dann spart man sich an tausenden Stellen die Absicherung der Threads gegeneinander mit critical sections.

-Michael

[mschnell]

Du willst doch eine nicht visuelles Programm bauen, oder?
Das Zauberwort im Main Loop heisst: Sleep()

Das sehe ich nicht so. Das programm muss auf diverse Sachen gleichzeitig reagieren können. Natürlich kann (und muss) man dafür Threads verwenden. Aber da die einzelnen Funktionalitäten Rückwirkungen auf einander haben, ist es sinnvoll, dass sie sich Mitteilungen zustellen können. Das geht "Delphi-like" am besten mit Messages (Windows oder Linux System-5). Ein Thread empfängt keine Messages solange er im "sleep" hängt, deshalb ist das Zauberwort "Warte auf Message Queue" (geht in Windows und Linux). Nur so kann man leicht gleichzeitig auf verschiedene Ereignisse (die von anderen Threads generiert werden) warten.

"Application" funktioniert genau so (Warten auf Windows oder QT Messages). Deshalb halte ich es für sinnvoll, sich an dieses Vorbild zu halten. Zum Glück ist ja alles im Sourcecode da .

Ich will versuchen, ein TApplication von TCustomApplication abzuleiten, das ja vermutlich keine Windows oder QT-Bindung hat und die Message-Queue von Hand zu implementieren.

-Michael

[mschnell]

Und was wollt ihr immer alle mit indy in einem visuellen programm kann ich es ja noch ansatzweise verstehen das man nicht visuele komponenten haben will aber in nem schlanken konsolenprogramm mit diesem ugly riesigen indy rumzuhantieren find ich blöd

Ein nicht visuelles Programm ist nicht unbedingt ein "einfaches Konsolen-Programm". In diesem Fall ist es ein dauernd laufendes "embedded" Programm, das über diverse serielle Schnittstellen und TCP/IP Verbindungen Daten mit anderen Systemen austauscht und Zeit-und Ereignis-gesteuert viele unterschiedliche Aktionen veranstaltet.

Indy könnte praktisch sein, da es u.U. HTTP-Server und/oder Client sein kann, über SMTP Mails verschicken und über SMTP(Server) oder IMAP Mails empfangen könnte, sich mit einem Time-Server synchronisieren muss etc.

-Michael

[Christian]

Kann synapse auch und schwieriger ist es auch nicht nur halt nichtvisuell was du ja eh musst. werden n paar zeilen code mehr dafür hast du wesentlich mehr kontrolle

[mschnell]

Kann synapse auch und schwieriger ist es auch nicht nur halt nichtvisuell was du ja eh musst. werden n paar zeilen code mehr dafür hast du wesentlich mehr kontrolle

Ich habe nix gegen Synapse einzuwenden (habe ich in Linux bisher genauso wenig getestet wie Indy ). Das ursprüngliche Delphi-Programm verwendet vermutlich die "alten" Delphi Socket-Komponenten, da muss also sowieso etwas portiert werden. Ich schaue mir Synapse auf jeden Fall an, bevor ich versuche Indy einzusetzen.

Aber Indy is nicht zwangsläufig "visual" Man kann die Komponenten zwar in der IDE auf ein Form platzieren, man kann sie aber auch programmatisch kreieren. Es gibt also keine wohl explizite Bindung an eine Programm-Oberfläche.

-Michael

[Christian]

Die gibt es bei keiner Komponenten trotsdem sind die Komponenten für die visuelle Programmierung geschrieben worden unbd das merkt man ihnen gewaltig an aber lassen wir des das führt eh zu nich (gut das ich nich immer das letzte wort haben muss )