Eigene Klasse und Messages

[Christian Schmitt]

Hallo Leute,

ich habe mir in einer eigenen Unit eine Klasse erstellt. Darin wird eine DLL angesprochen, welche wiederum Messages an das von meiner Klasse angegebene Handle schickt. Diese Message soll von meiner Klasse behandelt werden und einfach ein paar Variablen füllen. Soweit so einfach dachte ich. Ich habe also Prozeduren definiert á la

procedure OnMyEvent(var MSG: TMessage); message WM_USER;

Jetzt habe ich das Problem, dass wenn ich der externen DLL das Handle Application.Mainform.Handle (also vom Main-Window) als Message-Ziel mitgebe, dann reagiert meine Klasse nicht auf die Message. Lediglich mein Hauptfenster reagiert und auch nur wenn ich o.g. Prozedur in die TForm-Klasse einbinde. Ok, dachte ich, meine Klasse hat ja eigentlich keinen Bezug zu dem Main-Form, also verwende ich einfach Application.Handle, aber auch darauf reagiert OnMyEvent nicht. Ich habe es jetzt etwas unschön durch das Application.OnMessage Event gelöst, finde ich aber wie gesagt nicht sauber. Wenn aus irgendeinem Grund in der Hauptanwendung OnMessage belegt ist, überschreibt meine Klasse dies :-(

Was hab ich falsch gemacht?

Gruß

[Sven Lanoster]

Christian Schmitt schrieb:

[eigene Klasse soll Windows-Messages empfangen]

Post by Christian Schmitt
Was hab ich falsch gemacht?

Schau mal nach System.Classes.AllocateHWnd. Vorsicht, nicht Thread-Safe!

Wenn Du den Quelltext der VCL hast, kannst Du mal gucken, wie TTimer
implementiert ist.

Gruß,
Sven.

[Christian Schmitt]

Post by Sven Lanoster
[eigene Klasse soll Windows-Messages empfangen]

Post by Christian Schmitt
Was hab ich falsch gemacht?

Schau mal nach System.Classes.AllocateHWnd. Vorsicht, nicht Thread-Safe!

Klingt gut, was heißt an der stelle nicht Thread-Sicher? Ich greife doch nur einmalig auf AllocateHWnd zu, zum Erstellen des Handles? Natürlich klar, dass dann das Event vom gleichen Thread behandelt wird, oder gibt es da noch etwas zu beachten? In der Tat habe ich in meiner Anwendung mehrere Threads, daher danke schon mal für den Hinweis!!

Post by Sven Lanoster
Wenn Du den Quelltext der VCL hast, kannst Du mal gucken, wie TTimer
implementiert ist.

Sehr gutes Beispiel, danke, das werde ich mal testen!

Danke für deine Hilfe!!

Gruß

[Sven Lanoster]

Post by Christian Schmitt

Post by Sven Lanoster
Schau mal nach System.Classes.AllocateHWnd. Vorsicht, nicht
Thread-Safe!

Klingt gut, was heißt an der stelle nicht Thread-Sicher?

Wenn eine Windows-Nachricht an Application.Handle reinkommt, wird eine
Liste durchlaufen, in der sich Objekte eingetragen haben, die gerne
Nachrichten verarbeiten möchten. Das Eintragen in diese Liste macht
AllocateHWnd. Dabei werden globale Datenstrukturen verwendet. Solange
das alles wie geplant im Kontext des Main-Threads läuft, kann nichts
passieren, aber wenn AllocateHWnd von zwei Threads gleichzeitig
aufgerufen wird, gibts Ärger.

Post by Christian Schmitt
Ich greife doch nur einmalig auf AllocateHWnd zu, zum Erstellen des
Handles?

Und zwar im Kontext des Haupt-Threads.
Nachrichten an das Handle senden kann dann jeder Thread und Prozess.

Post by Christian Schmitt
Natürlich klar, dass dann das Event vom gleichen Thread behandelt
wird, oder gibt es da noch etwas zu beachten? In der Tat habe ich in
meiner Anwendung mehrere Threads, daher danke schon mal für den
Hinweis!!

Ein Thread hat bereits ein Handle an das seine Nachrichten gehen. Im
Execute ist üblicherweise eine "while not Terminated do"-Endlosschleife,
in der irgendwo Peekmessage und Dispatch steht.

Gruß,
Sven.

[Christian Schmitt]

Post by Sven Lanoster
Wenn eine Windows-Nachricht an Application.Handle reinkommt, wird eine
Liste durchlaufen, in der sich Objekte eingetragen haben, die gerne
Nachrichten verarbeiten möchten. Das Eintragen in diese Liste macht
AllocateHWnd. Dabei werden globale Datenstrukturen verwendet. Solange
das alles wie geplant im Kontext des Main-Threads läuft, kann nichts
passieren, aber wenn AllocateHWnd von zwei Threads gleichzeitig
aufgerufen wird, gibts Ärger.

Achso, gut, zur not tut es also ein einfaches synchronize...

Post by Sven Lanoster
Und zwar im Kontext des Haupt-Threads.
Nachrichten an das Handle senden kann dann jeder Thread und Prozess.

Das ist mir bekannt, dafür verwendet man ja u.a. auch gerne Messages, um zwischen Threads schnell mal was auszutauschen...

Post by Sven Lanoster
Ein Thread hat bereits ein Handle an das seine Nachrichten gehen. Im
Execute ist üblicherweise eine "while not Terminated do"-Endlosschleife,
in der irgendwo Peekmessage und Dispatch steht.

Ahja, stimmt. Sollte meine Klasse dann in einen eigenen Thread kommen (ist noch nicht so ganz sicher), dann kann ich auch das benutzen. Soweit hab ich auch noch nicht gedacht, danke!

Gruß

[Sven Lanoster]

Post by Christian Schmitt

Post by Sven Lanoster
Wenn eine Windows-Nachricht an Application.Handle reinkommt, wird
eine Liste durchlaufen, in der sich Objekte eingetragen haben, die
gerne Nachrichten verarbeiten möchten. Das Eintragen in diese Liste
macht AllocateHWnd. Dabei werden globale Datenstrukturen verwendet.
Solange das alles wie geplant im Kontext des Main-Threads läuft,
kann nichts passieren, aber wenn AllocateHWnd von zwei Threads
gleichzeitig aufgerufen wird, gibts Ärger.

Achso, gut, zur not tut es also ein einfaches synchronize...

Das Synchronize bekommt eine Procedure ohne Parameter. In dieser
Procedure wird AllocateHwnd aufgerufen, welches eine Methode haben
möchte, die Nachrichten für den Thread verarbeiten soll. Und diese
Methode wird dann vom Main-Thread mit Messages gefüttert, die den
gleichzeitig laufenden Thread steuern sollen.

Das fühlt sich furchtbar falsch an. Ich würde das lieber nicht machen.

Gruß,
Sven.

[Christian Schmitt]

Post by Sven Lanoster
Das Synchronize bekommt eine Procedure ohne Parameter. In dieser
Procedure wird AllocateHwnd aufgerufen, welches eine Methode haben
möchte, die Nachrichten für den Thread verarbeiten soll. Und diese
Methode wird dann vom Main-Thread mit Messages gefüttert, die den
gleichzeitig laufenden Thread steuern sollen.
Das fühlt sich furchtbar falsch an. Ich würde das lieber nicht machen.

Hmmm, ok, dh. die Message wird dann auch vom Main-Thread behandelt, weil ich AllocateHWnd vom Main-Thread habe aufrufen lassen? Das wäre dann in der Tat nicht so prikelnd. Also, bei mehreren Threads doch besser das Handle vom Thread benutzen!?

[Sven Lanoster]

[AllocateHwnd]
Hmmm, ok, dh. die Message wird dann auch vom Main-Thread behandelt,
weil ich AllocateHWnd vom Main-Thread habe aufrufen lassen? Das wäre
dann in der Tat nicht so prikelnd.

Als ich schrieb, dass AllocateHwnd nicht thread-safe ist, meinte ich,
dass man AllocateHwnd nicht mit Threads benutzt.

Also, bei mehreren Threads doch besser das Handle vom Thread
benutzen!?

Ja. Gute Idee! Könnte glatt von mir sein. :)

Gruß,
Sven.

[Hans-Peter Diettrich]

Post by Christian Schmitt
Hallo Leute,
ich habe mir in einer eigenen Unit eine Klasse erstellt. Darin wird
eine DLL angesprochen, welche wiederum Messages an das von meiner
Klasse angegebene Handle schickt. Diese Message soll von meiner
Klasse behandelt werden und einfach ein paar Variablen füllen. Soweit
so einfach dachte ich. Ich habe also Prozeduren definiert á la
procedure OnMyEvent(var MSG: TMessage); message WM_USER;
Jetzt habe ich das Problem, dass wenn ich der externen DLL das Handle
Application.Mainform.Handle (also vom Main-Window) als Message-Ziel
mitgebe, dann reagiert meine Klasse nicht auf die Message. Lediglich
mein Hauptfenster reagiert und auch nur wenn ich o.g. Prozedur in die
TForm-Klasse einbinde.

Klar, Messages an MainForm werden vom MainForm Handler verarbeitet.
Siehe WndProc, WindowProc...

Ich vermute mal, daß Deine Klasse von TComponent abgeleitet werden
sollte. Das Handlw muß ja irgendwo ausgewertet werden, um den
zugehörigen Handler zu ermitteln. AFAIR geschieht das durch Suchen in
den Components[] Listen der Forms. Und dort packst Du Dein TComponent
mit rein.

Post by Christian Schmitt
Ich
habe es jetzt etwas unschön durch das Application.OnMessage Event
gelöst, finde ich aber wie gesagt nicht sauber. Wenn aus irgendeinem
Grund in der Hauptanwendung OnMessage belegt ist, überschreibt meine
Klasse dies :-(

Da muß ein einziger Handler alle Messages an die zusätzlichen Handles
bearbeiten.

Eine andere Lösung wäre eine Callback-Funktion, die ohne Suchen direkt
von der DLL aufgerufen werden kann. Aber dafür muß natürlich die DLL
mitspielen.

DoDi

[Christian Schmitt]

Post by Hans-Peter Diettrich
Ich vermute mal, daß Deine Klasse von TComponent abgeleitet werden
sollte. Das Handlw muß ja irgendwo ausgewertet werden, um den
zugehörigen Handler zu ermitteln. AFAIR geschieht das durch Suchen in
den Components[] Listen der Forms. Und dort packst Du Dein TComponent
mit rein.

TTImer ist doch auch von TComponent abgeleitet und muß sich trotzdem ein eigenes Handle besorgen (AllocateHWnd). Oder habe ich dich jetzt falsch verstanden? Oder meinst du Application.Handle wird an alle TComponents weitergeleitet? Falls dem so wäre, warum besorgt sich TTimer ein neues Handle? Ist Application.Handle irgendwie unsauber?

Post by Hans-Peter Diettrich
Da muß ein einziger Handler alle Messages an die zusätzlichen Handles
bearbeiten.

Ja, das ist mir bewußt, daher gefällt mir die Lösung ja nicht wirklich. Und wie gesagt, sollte die Hauptanwendung aus irgend einem Grund ebenfalls das OnApplication-Event belegen, dann funktioniert meine Klasse nicht mehr richtig und BAM...

Post by Hans-Peter Diettrich
Eine andere Lösung wäre eine Callback-Funktion, die ohne Suchen direkt
von der DLL aufgerufen werden kann. Aber dafür muß natürlich die DLL
mitspielen.

Stimmt, muß ich einmal recherchieren, ob die DLL das kann. Dann wäre ich natürlich aus dem Schneider..

Danke auch dir!

[OT] Ich war schon länger nicht mehr hier, es ist ja gar nicht mehr soviel los. Heißt das, dass Delphi mehr und mehr unpopulär wird? Sollte ich mich bald nach einer neuen Sprache umschauen, allein schon wegen eurem Support :-)?
[/OT]

Gruß

[Hans-Peter Diettrich]

Am Dienstag, 3. Januar 2017 01:52:42 UTC+1 schrieb Hans-Peter

Post by Hans-Peter Diettrich
Ich vermute mal, daß Deine Klasse von TComponent abgeleitet werden
sollte. Das Handlw muß ja irgendwo ausgewertet werden, um den
zugehörigen Handler zu ermitteln. AFAIR geschieht das durch Suchen
in den Components[] Listen der Forms. Und dort packst Du Dein
TComponent mit rein.

TTImer ist doch auch von TComponent abgeleitet und muß sich trotzdem
ein eigenes Handle besorgen (AllocateHWnd). Oder habe ich dich jetzt
falsch verstanden? Oder meinst du Application.Handle wird an alle
TComponents weitergeleitet? Falls dem so wäre, warum besorgt sich
TTimer ein neues Handle? Ist Application.Handle irgendwie unsauber?

Das Handle ist die Adresse des Empfängers. Messages an
Application.Handle müssen in Application.OnMessage verarbeitet werden.
Alle TWinControl Abkömmlinge ereugen ein Window für jede Instanz, an
dessen Handle Messages geschickt werden können.

Post by Hans-Peter Diettrich
Da muß ein einziger Handler alle Messages an die zusätzlichen
Handles bearbeiten.

Ja, das ist mir bewußt, daher gefällt mir die Lösung ja nicht
wirklich. Und wie gesagt, sollte die Hauptanwendung aus irgend einem
Grund ebenfalls das OnApplication-Event belegen, dann funktioniert
meine Klasse nicht mehr richtig und BAM...

Wie stellst Du Dir die Weiterleitung von Messages vor? Dazu braucht
jedes Programm (bzw. jeder Thread) eine message-pump, die regelmäßig
neue Messages von Windows abholt und dann an die Empfänger
weiterverteilt. Dazu hat Application eine Liste aller Forms, und fragt
die der Reihe nach, ob sie eine Message behandeln. Die Forms (windows)
haben dann eine Liste ihrer Unter-Fenster (Components[]), die sie
ihrerseits abklappern. So ist das jedenfalls in Delphi implementiert.

Wenn Du mehrere Handles ohne zugehörige Windows benutzen möchtest,
kannst Du eine neue Verwaltungsklasse erzeugen, bei der alle derartige
Handles registriert werden. Dazu könnte ein globales Objekt ExtraHandles
erzeugt werden, bei dem sich alle Deine Handler registrieren lassen.
Dieses Objekt wird in Application.OnMessage eingeklinkt, und kann dann
alle bei ihm registrierten Handles abklappern, wenn eine neue Message
angekommen ist.

[OT] Ich war schon länger nicht mehr hier, es ist ja gar nicht mehr
soviel los. Heißt das, dass Delphi mehr und mehr unpopulär wird?
Sollte ich mich bald nach einer neuen Sprache umschauen, allein schon
wegen eurem Support :-)? [/OT]

Vermutlich läuft der Traffic inzwischen mehr über die Embarcadero Foren.
Zur Popularität von Delphi kann ich nichts sagen, für meine Projekte
bleibe ich bei D7, da brauche ich nur noch ganz selten Hilfe. XE4 habe
ich auch noch, aber mangels Interesse an Unicode ist das für mich vor
allem aufgrund der mickrigen Online-Hilfe nicht sehr attraktiv.
Vielleicht mal für 64 Bit Programme, aber auch da ist mein privater
Bedarf gering. Lazarus habe ich eine Zeit lang benutzt, wäre noch eine
Alternative für Linux Programe. Ansonsten beschäftige ich mich derzeit
mit Arduinos, für die es kein Pascal gibt, da wäre dann Ada eine
Alternative.

Mit RAD Studio bekommt man auch C++ und (immer noch?) RemObjects für
.NET, und wäre damit auch für den großen Markt gerüstet, sofern das
gewünscht wird und kein anderes Entwicklungssystem vorgeschrieben wird.
Zu Mobiles und Apps kann ich nichts sagen, darin werde ich mich nicht
mehr einarbeiten.

DoDi

[Christian Schmitt]

Post by Hans-Peter Diettrich
Das Handle ist die Adresse des Empfängers. Messages an
Application.Handle müssen in Application.OnMessage verarbeitet werden.
Alle TWinControl Abkömmlinge ereugen ein Window für jede Instanz, an
dessen Handle Messages geschickt werden können.

Das ist mir soweit klar...

Post by Hans-Peter Diettrich
Wie stellst Du Dir die Weiterleitung von Messages vor? Dazu braucht
jedes Programm (bzw. jeder Thread) eine message-pump, die regelmäßig
neue Messages von Windows abholt und dann an die Empfänger
weiterverteilt. Dazu hat Application eine Liste aller Forms, und fragt
die der Reihe nach, ob sie eine Message behandeln. Die Forms (windows)
haben dann eine Liste ihrer Unter-Fenster (Components[]), die sie
ihrerseits abklappern. So ist das jedenfalls in Delphi implementiert.

Und warum muß TTimer=class(TComponent) sich dann mit AllocateHWnd ein Handle "besorgen". Wieso bekommt der dann die Timer-Message nicht weitergeleitet? Oder ist das einfach halt nur anders gelöst?

Post by Hans-Peter Diettrich
Wenn Du mehrere Handles ohne zugehörige Windows benutzen möchtest,
kannst Du eine neue Verwaltungsklasse erzeugen, bei der alle derartige
Handles registriert werden. Dazu könnte ein globales Objekt ExtraHandles
erzeugt werden, bei dem sich alle Deine Handler registrieren lassen.
Dieses Objekt wird in Application.OnMessage eingeklinkt, und kann dann
alle bei ihm registrierten Handles abklappern, wenn eine neue Message
angekommen ist.

Klingt ganz schön kompliziert für nur 3 Messages :-). Spricht aus deiner Sicht etwas gegen AllocateHWnd? Das hätte ich mit 3 Zeilen implementiert...

Post by Hans-Peter Diettrich

Post by Christian Schmitt
[OT] Ich war schon länger nicht mehr hier, es ist ja gar nicht mehr
soviel los. Heißt das, dass Delphi mehr und mehr unpopulär wird?
Sollte ich mich bald nach einer neuen Sprache umschauen, allein schon
wegen eurem Support :-)? [/OT]

Vermutlich läuft der Traffic inzwischen mehr über die Embarcadero Foren.
Zur Popularität von Delphi kann ich nichts sagen, für meine Projekte
bleibe ich bei D7, da brauche ich nur noch ganz selten Hilfe.

Das merkt man dir an :-)

Post by Hans-Peter Diettrich
XE4 habe
ich auch noch, aber mangels Interesse an Unicode ist das für mich vor
allem aufgrund der mickrigen Online-Hilfe nicht sehr attraktiv.
Vielleicht mal für 64 Bit Programme, aber auch da ist mein privater
Bedarf gering. Lazarus habe ich eine Zeit lang benutzt, wäre noch eine
Alternative für Linux Programe. Ansonsten beschäftige ich mich derzeit
mit Arduinos, für die es kein Pascal gibt, da wäre dann Ada eine
Alternative.
Mit RAD Studio bekommt man auch C++ und (immer noch?) RemObjects für
.NET, und wäre damit auch für den großen Markt gerüstet, sofern das
gewünscht wird und kein anderes Entwicklungssystem vorgeschrieben wird.
Zu Mobiles und Apps kann ich nichts sagen, darin werde ich mich nicht
mehr einarbeiten.

Okay, thx, ich werde mir die Sachen mal ansehen. Bisher bin ich mit Delphi eigentlich immer gut gefahren auch wenn mich so manch einer schräg anschaut. Es gibt sehr viele Komponenten und auch eine große Community, ich hab bisher noch alles hinbekommen. Also kein Grund zu wechseln ;-)

Gruß

[Hans-Peter Diettrich]

Post by Christian Schmitt

Post by Hans-Peter Diettrich
Wie stellst Du Dir die Weiterleitung von Messages vor? Dazu braucht
jedes Programm (bzw. jeder Thread) eine message-pump, die
regelmäßig neue Messages von Windows abholt und dann an die
Empfänger weiterverteilt. Dazu hat Application eine Liste aller
Forms, und fragt die der Reihe nach, ob sie eine Message behandeln.
Die Forms (windows) haben dann eine Liste ihrer Unter-Fenster
(Components[]), die sie ihrerseits abklappern. So ist das
jedenfalls in Delphi implementiert.

Und warum muß TTimer=class(TComponent) sich dann mit AllocateHWnd ein
Handle "besorgen". Wieso bekommt der dann die Timer-Message nicht
weitergeleitet? Oder ist das einfach halt nur anders gelöst?

Die TWinComponent Abkömmlinge erzeugen immer ein Window, in dem sie
dargestellt werden, und haben deshalb ein Window-Handle. Andere Controls
(TLabel...) benötigen kein eigenes Fenster für ihre Darstellung, und
haben deshalb kein Handle, können keine Messages empfangen, und werden
beim Redraw ihres Parents in PaintControls dargestellt.

Wieder andere (unsichtbare) Components wie TTimer müssen sich ein
Window-Handle selbst besorgen, damit sie Messages empfangen können. Sie
landen dann in Owner.Controls[], und empfangen IMO von dem auch ihre
Messages.

Post by Christian Schmitt

Post by Hans-Peter Diettrich
Wenn Du mehrere Handles ohne zugehörige Windows benutzen möchtest,
kannst Du eine neue Verwaltungsklasse erzeugen, bei der alle
derartige Handles registriert werden. Dazu könnte ein globales
Objekt ExtraHandles erzeugt werden, bei dem sich alle Deine Handler
registrieren lassen. Dieses Objekt wird in Application.OnMessage
eingeklinkt, und kann dann alle bei ihm registrierten Handles
abklappern, wenn eine neue Message angekommen ist.

Nachtrag: Vermutlich kann auch TComponent als fertige Basisklasse
verwendet werden - siehe TTimer.

Post by Christian Schmitt
Klingt ganz schön kompliziert für nur 3 Messages :-). Spricht aus
deiner Sicht etwas gegen AllocateHWnd? Das hätte ich mit 3 Zeilen
implementiert...

AllocateHwnd reicht vermutlich nicht. Zumindest braucht Deine Klasse
noch eine Methode WndProc, die dann beim Eintreffen einer Message
irgendwie aufgerufen wird. Bei einem TComponent dürfte das über den
Owner implementiert sein. Zumindest funktioniert das alles bei TTimer,
und der stammt ja von TComponent ab.

DoDi

[Christian Schmitt]

Post by Hans-Peter Diettrich
Die TWinComponent Abkömmlinge erzeugen immer ein Window, in dem sie
dargestellt werden, und haben deshalb ein Window-Handle. Andere Controls
(TLabel...) benötigen kein eigenes Fenster für ihre Darstellung, und
haben deshalb kein Handle, können keine Messages empfangen, und werden
beim Redraw ihres Parents in PaintControls dargestellt.
Wieder andere (unsichtbare) Components wie TTimer müssen sich ein
Window-Handle selbst besorgen, damit sie Messages empfangen können. Sie
landen dann in Owner.Controls[], und empfangen IMO von dem auch ihre
Messages.
[...]
AllocateHwnd reicht vermutlich nicht. Zumindest braucht Deine Klasse
noch eine Methode WndProc, die dann beim Eintreffen einer Message
irgendwie aufgerufen wird. Bei einem TComponent dürfte das über den
Owner implementiert sein. Zumindest funktioniert das alles bei TTimer,
und der stammt ja von TComponent ab.

Ahjetztja, danke schon einmal für die Einführung in die Messagebehandlung, so langsam steige ich glaube ich durch. Habt Ihr eigentlich dieses Know How euch angelesen (Quellcode auswendig gelernt :-) ) oder ist das alles Erfahrung? Jedenfalls Daumen hoch!

Thx nochmal!
Gruß

[Hans-Peter Diettrich]

Am Freitag, 6. Januar 2017 01:03:24 UTC+1 schrieb Hans-Peter
Ahjetztja, danke schon einmal für die Einführung in die
Messagebehandlung, so langsam steige ich glaube ich durch. Habt Ihr
eigentlich dieses Know How euch angelesen (Quellcode auswendig
gelernt :-) ) oder ist das alles Erfahrung? Jedenfalls Daumen hoch!

Mit Win3 habe ich mich seinerzeit intensiv befaßt, die SDK Hilfe auf
Deutsch übersetzt und getestet, was mir nicht geheuer war[1]. Was tut
man nicht alles, wenn man wochenlang im Bett liegen muß...

Mein Delphi-Wissen hat sich jetzt allerdings als nicht ganz zuverlässig
herausgestellt, da scheint Sven besser informiert zu sein. Es ist ja
auch schon etliche Jahre her, daß ich mich mit Messages in Delphi
herumgeschlagen habe, und Threads habe ich nie ernsthaft verwendet.


[1] Zu der Zeit (1990) habe ich mir mein erstes Notebook angeschafft,
mit 4MB RAM und 80MB Platte, und Word1 lief darauf prima. Delphi gab's
noch nicht, dafür war der BC3.1 um Längen besser als MSC[2]. Den BC3
hatte ich im Beta-Test für Windows und Atari ST bekommen. Auf dem Atari
habe ich meinen C Discompiler für BC3 aufgebohrt, und auf dessen
Systembibliotheken losgelassen, die nicht im Quellcode zugänglich waren,
und gleich Fehler und Murks darin gefunden. Dafür habe ich aber
GfA-Basic benutzt, die ultimative Sprache für den ST. Auch auf dem PC
blieb ich bei VB3, aber seit D4 habe ich praktisch nur noch in Delphi
programmiert.

[2] Seit dem SDK für Win95 weiß ich, wie beschissen MS Compiler und ihre
Programmierer sind/waren. Der BCB4 hat in jedem getesteten Sample zum
SDK über 50 (meist haarsträubende) Fehler gefunden[3], seitdem wundere
ich mich nur noch, warum Windows überhaupt läuft. Der "Compiler" für VB5
war auch der Hammer, der hat nur nach Lust und Laune compiliert, ganz
sicher nicht das, was im Quelltext stand, und die Verzweiflung der
MS-Programmierer war mit Händen zu greifen, wenn sie in den Samples
wieder mal einen Versuch gestartet haben, die Compilerfehler mit neuen
Hacks zu umschiffen. Meist vergeblich :-(

[3] Vielleicht waren die Fehler in den SDK Samples auch Absicht? Nach
dem Rauswerfen der überflüssigen und oft falschen Typecasts hat der BCB
jedenfalls erschreckend viele Fehler gefunden. War der MSC so schlecht,
daß man den nur mit Typecasts überreden konnte, halbwegs richtigen Code
zu erzeugen, oder Verzweiflung der Programmierer? Damals hat MS ja mit
allen Mitteln versucht, sich Mitbewerber vom Hals zu halten. Jedes
Windows Update enthielt neue Funktionen und Fehler[4], welche die
Konkurrenz erst einmal finden mußte, bevor ihre Entwicklungssysteme
richtig lauffähige Programme produzieren konnten. Anders hätten sie ihr
eigenes Entwicklungssystem (MSVC) sicher nicht im Markt durchdrücken
können. Für .NET haben sie die Delphi-Entwickler abgeworben, die haben
dann auch das erste akzeptable System geschaffen. Seitdem ging es mit
Delphi nur noch bergab, Embarcadero mußte sogar Anleihen bei Free Pascal
machen, um einen 64 Bit Compiler auf die Beine zu stellen :-(

[4] Ein Bekannter hat in jeder neuen Version ausprobiert, mit welchen
Puffergrößen die Speicherverwaltung von Windows versagt. Diese Größen
wurden zwar immer wieder hin- und hergeschoben, aber dank C kann wohl
niemand feststellen, wo die Ursachen dafür liegen. Deshalb habe ich mir
auch mal Reactos angeschaut, aber da das auch in C programmiert ist... :-(

Deshalb beschäftige ich mich jetzt lieber mit Arduinos, da sind selbst
die Systembibliotheken noch ganz gut verständlich. Und es macht mehr
Spaß, wieder einmal in den Hardware-Features zu wühlen, und Schaltungen
zusammenzustöpseln oder zu löten :-)

DoDi

[Sven Lanoster]

Post by Christian Schmitt
Habt Ihr eigentlich dieses Know How euch angelesen (Quellcode
auswendig gelernt :-) ) oder ist das alles Erfahrung?

Ja (ja) und ja!

Mein damaliger Chef hatte mich mit einer Delphi 1 Alpha-Version (V
0.9a?) angefixt. Da gabs noch mehrere Kilo Papier-Doku dazu. Und die
"Online"-Hilfe war informativ.

Dann wurde es immer wichtiger, sich im Quellcode der VCL zurecht zu
finden. Nicht nur, dass da ein nützlicher Quicksort herumliegt, am
Anfang war die VCL leider auch weder fehlerfrei noch vollständig.

Nicht lange und wir hatten in der Palette nur noch eigene Ableitungen.
So konnten wir zum Beispiel fehlende Assign(To) einbauen. Oder das
grottenlahme FieldByName in TDataset durch etwas eigenes ersetzen. Das
Original lädt bei jedem Aufruf die Spracheinstellungen des Users, um in
Spaltennamen der Tabellen auch Sonderzeichen zu unterstützen. "Ich glaub
es hackt! Wer Sonderzeichen für die Bezeichnung seiner Tabellenfelder
verwendet, hat Ärger verdient." meinte mein Chef damals. Das hat meine
Import-Programme von "läuft über Nacht" auf "halbe Stunde" gebracht.

Damit hätten wir "angelesen" (die Doku) und "Quellcode auswendig
gelernt". Bleibt noch Erfahrung.

Ich hab Delphi bis D7 hauptberuflich gemacht. Und dann andere Dinge.
Privat hatte ich dann nur ein D7-Hobby-Kostenlos-Dings ohne
VCL-Quellcode. Das war nur so mittel-spaßig. Lazarus hat sich echt toll
entwickelt und ist inzwischen echt geil. Ist aber nicht Delphi.

Da ich den Delphi-Entzug nicht mehr ausgehalten habe, arbeite ich
inzwischen wieder als Delphi-Entwickler.

Und kämpfe mit COM, Java-Native-Interface und VM mit historischen
Delphi-Versionen auf historischen Betrübssystemen, die noch gebraucht
werden, weil die benutzten Fremdbibliotheken nicht mehr gepflegt werden
und nicht ersetzt werden können. Alles Dinge, von denen ich keinen
Schimmer hatte. Wenn es nicht so viel Spaß machen würde, müsste ich
(mehr) Geld verlangen.

Andererseits habe ich offenbar genug Geld. Ich habe mir neulich ein D10
prof. für privat gekauft. Ich benutze es nicht, aber es ist gut zu
wissen, dass ich es könnte. :)

Gruß,
Sven.

[Christian Schmitt]

Ohwei, ich hab noch einiges vor mir :-)

Danke nochmals!