Data Binding

[Stevie]

Wer schon mit .Net zu tun hatte, wird sie kennen und schätzen gelernt haben: Data Bindings.
Man kann dort nahezu alles aneinander binden. Sei es, um Listen von Objekten in Trees, Lists oder Grids darzustellen oder Eigenschaften von Objekten in Text-, Check- oder Comboboxen editierbar zu machen.
Oder sogar die Sichtbarkeit oder das Aussehen einzelner Controls zu beinflussen.

Wie das genau funktioniert, kann man in der MSDN nachlesen.

Ja und? In Delphi gibts DataSet, DataSource und diverse datensensitive Controls, um das zu bewerkstelligen!
Richtig, die Sache hat nur einen Haken: Man kann nicht einfach ein 08/15 Objekt daran hängen. Sicher, es gibt TSnapObjectDataset oder spezielle Controls, mit denen man das machen kann. Hat aber den entscheidenden Nachteil, dass man immer entweder besondere Controls oder Komponenten haben muss oder seine bindbaren Objekte von einer Basisklasse ableiten muss.

Ich hab mir mal einige Dinge von der .Net Implementierung abgeschaut und das ganze in Delphi mit folgenden Zielsetzung nachgebaut:

• Standard Komponenten und Controls müssen unterstützt werden (z.B. TEdit)
• wenig bis keine extra Implementierung für bindbare Objekte
• minimaler Sourcecode, um Objekte aneinander zu binden

Ok, fangen wir an. Was brauchen wir?

Ein Binding braucht immer eine Source und ein Target (beides ein Objekt) und die Namen der zu bindenden Eigenschaften.
Für unser erstes Beispiel bauen wir uns eine einfache Klasse, die 2 Eigenschaften hat:

Delphi-Quellcode:

type
  TSettings = class
  private
    FCaption: string;
    FColor: TColor;
    procedure SetCaption(const Value: string);
    procedure SetColor(const Value: TColor);
  public
    property Caption: string read FCaption write SetCaption;
    property Color: TColor read FColor write SetColor;
  end;

implementation

procedure TSettings.SetCaption(const Value: string);
begin
  FCaption := Value;
end;

procedure TSettings.SetColor(const Value: TColor);
begin
  FColor := Value;
end;

Wir haben hier schonmal explizite Setter Methoden - die brauchen wir später noch. Aber für das erste Beispiel würde auch in direkter Zugriff auf die Feldvariable genügen.

So, was machen wir nun mit unserem TSettings Objekt? Wir erzeugen 2 Bindings, die auf den Titel und die Farbe unserer MainForm gehen.

Delphi-Quellcode:

procedure TMainForm.FormCreate(Sender: TObject);
begin
  FSettings := TSettings.Create;
  FSettings.Caption := 'Binding demo';
  FSettings.Color := clGray;
  TBinding.Create(FSettings, 'Caption', MainForm, 'Caption');
  TBinding.Create(FSettings, 'Color', MainForm, 'Color');
end;

Dazu genügt es, die Unit System.Bindings einzubinden. Auch um das Freigeben der Binding Objekte braucht man sich nicht kümmern solange mindestens eins der beiden verbundenen Objekte von TComponent abgeleitet ist (in unserem Fall ist es das MainForm).

Starten wir die Anwendung und sehen, was passiert. Titel und Farbe des MainForms ist entsprechend der Werte aus unserem TSettings Objekts gesetzt worden. Toll, oder?
Naja, da hätts auch das explizite Zuweisen der Werte getan... Klar, aber der eigentliche Clou der Bindings kommt erst noch!

Packen wir mal einen Button auf die Form und setzen dort die Eigenschaft unseres Settings Objekts:

Delphi-Quellcode:

procedure TMainForm.Button1Click(Sender: TObject);
begin
  FSettings.Caption := 'Current time: ' + DateTimeToStr(Now);
end;

Da tut sich erstmal nix, aber wir sind auch noch nicht fertig. Gehen wir zurück zu unserer TSettings Klasse und passen sie etwas an.
Wir leiten sie mal von einem Basis Objekt ab, welches ein Interface implementiert - und zwar INotifyPropertyChanged. Auch das ist wieder brav von .Net abgekupfert.
Aha, nun brauchen wir also unsere Setter Methoden für die Eigenschaften.

So sieht unserer modifizierte Klasse nun aus:

Delphi-Quellcode:

type
  TSettings = class(TPropertyChangedBase)
  private
    FCaption: string;
    FColor: TColor;
    procedure SetCaption(const Value: string);
    procedure SetColor(const Value: TColor);
  public
    property Caption: string read FCaption write SetCaption;
    property Color: TColor read FColor write SetColor;
  end;

implementation

procedure TSettings.SetCaption(const Value: string);
begin
  FCaption := Value;
  DoPropertyChanged('Caption');
end;

procedure TSettings.SetColor(const Value: TColor);
begin
  FColor := Value;
  DoPropertyChanged('Color');
end;

Tadaa, und auf Knopfdruck wird nun auch der Titel unserer MainForm geändert. Naja, ganz putzig, aber so richtig rocken tut's noch nicht, oder?

Na gut, werfen wir mal ein TEdit auf die Form und binden es ebenfalls im Konstruktor des MainForms an die Caption Eigenschaft unseres TSettings Objekts:

Delphi-Quellcode:

...
TBinding.Create(FSettings, 'Caption', Edit3, 'Text');

Toll, nun steht der Titel des Forms auch im Edit drin... und wenn ich dort drin änder passiert nix!
Stimmt, es fehlt noch was. Als letzte Unit (genauer gesagt nach den Units, in denen die Controls drin sind, an die ich binden möchte) im uses des Interface Teils des Forms muss die Unit System.Bindings.Controls.
Dort befinden sich einige Ableitungen von Standard VCL Controls mit dem gleichen Namen, welche das INotifyPropertyChanged Interface implementieren. Und dadurch, dass sie als letzte (oder zumindest nach den entsprechenden Units steht) werden beim Erstellen des Forms Objekte von den abgeleiteten Klassen erstellt. Das heißt im Klartext, es müssen keine speziellen Controls oder Komponenten auf der Form verbaut werden, damit man das Data Binding nutzen kann.

Starten wir mal die Anwendung und tippern ein wenig im Edit rum. Wow, der Titel des Forms ändert sich!

Um es nochmal zu betonen:

• keine speziellen Controls nötig (nur das Subclassing von Controls, die man Binding fähig machen möchte)
• keine speziellen Events nötig
• als read-once Source können direkte Ableitungen von TObject benutzt werden (lediglich für die Benachrichtigung von Eigenschaftsänderungen ist das Interface nötig)
• minimaler Sourcecode, um Objekte, Komponenten und Controls zu verbinden.

Im angehangenden Beispiel sind noch einige weitere Bindings und Controls auf der Form, mit welchen man einige Eigenschaften verändern kann.
Das ganze wurde unter Delphi XE entwickelt. Delphi 2010 könnte auch funktionieren, aber da waren die Generics noch ein wenig verbuggt. Alle Versionen darunter sind leider nicht unterstützt. Das liegt am regen Gebrauch von Generics und neuer RTTI.

Außerdem findet ihr in den benötigten Units noch weitere Dinge wie zum Beispiel Multicast Events oder den NotificationHandler, der dafür zuständig ist, dass die TBinding Objekte ohne Zutun freigegeben werden.

In Planung und teilweise schon realisiert sind Bindings für Listen in dementsprechenden Controls (z.B. ListBox)

Anregungen, Kritik und Fragen sind herzlich willkommen und sehr erwünscht.


P.S.: Crosspost bei Delphi-Forum

Update 18.06.2011:

• Source der Library aktualisiert (enthält den kompletten Code meiner DSharp Library)
• aktuelle Samples für data binding hinzugefügt

Update 10.04.2012:

• veraltete Archive entfernt (aktuelle und supportete Version im svn Repository)

[stahli]

Hi Stevie,

sorgst Du gerade dafür, dass es weniger Argumente für einen Umstieg von Delphi auf .net gibt???

Ich habe es mir noch noch nicht angesehen und werde das mal am Wochenende tun, bezweifle aber, dass ich die Details wirklich nachvollziehen kann. Trotzdem mal ein paar Fragen:

Das DataBinding war ja immer ein Pro-Net-Argument. Jetzt würde dann eine Einrichtung der Bindings wohl nur noch in der Delphi-IDE fehlen?

Nach meiner (derzeitigen) Einschätzung wird die Binding-Option jedoch auch überbewertet, oder ist zumindest allein noch kein sehr wirksames Arbeitsmittel.

Wichtiger ist es m.E. Objekte leicht zu definieren und den Export/Import und Abfrage der Daten zu regeln.

Die Binding-Technologie ist sicher sehr interessant und hilfreich, aber eben nur ein Punkt bei der Arbeit mit Objekten.

Wie komfortabel die Objekte aber erzeugt und mit Daten gefüllt werden können, ist aber damit ja noch nicht gelöst. Ebenso nicht die Abfrage von Daten (Selektionen aus Listen).

Da wäre ein "LINQ to Objects" für Delphi sicher noch interessanter.

Zitat:

Außerdem findet ihr in den benötigten Units noch weitere Dinge wie zum Beispiel Multicast Events oder den NotificationHandler, der dafür zuständig ist, dass die TBinding Objekte ohne Zutun freigegeben werden.

Berührt dieser Bereich ggf. dieses Thema?

Ich weiß, mein Beitrag ist etwas unscharf gefasst - entspricht aber damit meinem derzeitigen Kenntnisstand des Themas
Außerdem hast Du eine Antwort verdient (auch wenn es eben erst mal nur solch eine ist)


Ich bin gerade auch dabei, ein Projekt komplett mit Objekten aufzubauen und eine Anbindung an Ableitungen von Standardkomponenten zu regeln. Der Nachteil ist sicher, dass den Standardcontrols zusätzliche Eigenschaften und Methoden verpasst werden müssen und die Datenobjekte von einem Basisobjekt abgeleitet werden müssen. Andererseits passt so alles sehr gut zusammen und kann aufeinander abgestimmt werden. Einen wirklichen Nachteil kann ich darin letztlich auch nicht erkennen, zumal auch die Datenspeicherung in dem Basisobjekt definiert ist.


PS: Wie (ungefähr) regelt eigentlich die IDE selbst die Bearbeitung von Objekteigenschaften im Objektinspektor? Da muss ja eine ähnliche Bindung realisiert sein? Kann das jemand grob erklären?

[Stevie]

Zitat von stahli:

sorgst Du gerade dafür, dass es weniger Argumente für einen Umstieg von Delphi auf .net gibt???

Naja, ich bin nach wie vor großer Fan von Delphi und wenn ich mir Dinge in .Net anschaue, bekomm ich immer Tränen in den Augen, was da so alles funktioniert.
Deshalb baue ich viele Sachen nach bzw versuche es. Und bei den meisten Dingen gelingt das auch (siehe meine anderen Posts in jüngerer Zeit).
Liegt daran, dass Delphi XE die erste Version ist, die nicht alle Nase lang die Generics (unerlässlich für das meiste, was ich veranstalte) auseinander fliegen lässt beim Kompilieren und halt die erweiterte RTTI seit 2010.

Zitat von stahli:

Das DataBinding war ja immer ein Pro-Net-Argument. Jetzt würde dann eine Einrichtung der Bindings wohl nur noch in der Delphi-IDE fehlen?

Plump gesagt ja. Es fehlen wie gesagt noch eine Menge Dinge für ein .Net vergleichbares Binding, aber der Grundstein ist imho gelegt. Außerdem ist das ganze kein Selbstzweck, sondern ich ich brauchte die Bindings für andere Dinge (dazu später mehr). Ich hatte schon über eine Komponente (würde dann wahrscheinlich auf eine Art BindingGroup Nachbau hinauslaufen) nachgedacht, die man auf Forms, Frames oder DataModules pappen kann.

Zitat von stahli:

Nach meiner (derzeitigen) Einschätzung wird die Binding-Option jedoch auch überbewertet, oder ist zumindest allein noch kein sehr wirksames Arbeitsmittel.

Sobald du Anwendungen schreibst, die einen Schwerpunkt auf Anzeige von Daten haben, willst du sie nicht mehr missen. Objektliste an ne Treeview gebunden, paar Einstellungen gemacht und bumm, werden die Daten angezeigt (und mit einigen mehr Handgriffen auch editierbar)

Zitat von stahli:

Wichtiger ist es m.E. Objekte leicht zu definieren und den Export/Import und Abfrage der Daten zu regeln.

Die Binding-Technologie ist sicher sehr interessant und hilfreich, aber eben nur ein Punkt bei der Arbeit mit Objekten.

Wie komfortabel die Objekte aber erzeugt und mit Daten gefüllt werden können, ist aber damit ja noch nicht gelöst. Ebenso nicht die Abfrage von Daten (Selektionen aus Listen).

Da wäre ein "LINQ to Objects" für Delphi sicher noch interessanter.

Gute Vorlage, auch sowas gibts schon, schau dir mal Delphi Collections an. Eine weitaus mächtigere Collections library als das aus Generics.Collections.pas. Damit hast du eigentlich schon "LINQ to Objects" nur ohne die fancy build in Syntax wie in .Net. Du musst das dann halt über die Methoden aufrufen. Die fehlenden Lambda Ausdrücke machen die Code auf Delphi Seite natürlich ein bisschen länger als man ihn in C# schreiben kann, aber kurzer Quellcode war ja noch nie das Ziel von Delphi und ist imho auch nicht schlimm.
Was darfs noch sein? "LINQ to XML" vielleicht? Ein erster Prototyp von "LINQ to SQL" (bzw eher ne Art Entity Framework "light" Nachbau) ist auch schon in der Mache, da haperts aber für die Generierung von vernünftigen SQL Statements (abgesehen von nem full table select) noch etwas. Vor allem Mangels ExpressionTrees der delegates, die in .Net "einfach" in SQL umgebaut werden. Bisher gehen einfache Abfragen aber komplette Codegenerierung für Datenklassen über Metadaten aus nem SQL Server Datenbank Schema ist bereits implementiert.

Zitat von stahli:

Zitat:

Außerdem findet ihr in den benötigten Units noch weitere Dinge wie zum Beispiel Multicast Events oder den NotificationHandler, der dafür zuständig ist, dass die TBinding Objekte ohne Zutun freigegeben werden.

Berührt dieser Bereich ggf. dieses Thema?

Ich weiß, mein Beitrag ist etwas unscharf gefasst - entspricht aber damit meinem derzeitigen Kenntnisstand des Themas

Bedingt, es geht eher darum, dass auch nicht von TComponent abgeleitete Objekte über die TComponent eigene Notification benachrichtigt werden, wenn sich dort etwas getan hat. So werden z.B. die Bindings freigegeben, wenn Source oder Target freigegeben werden (wenn sie von TComponent abgeleitet sind). Das heißt aber, dass wenigstens einer der Akteure ein TComponent sein muss, damit das funktioniert.

Zitat von stahli:

Außerdem hast Du eine Antwort verdient (auch wenn es eben erst mal nur solch eine ist)

Danke, ich beschäftige mich wohl mit zu komplizierten oder für die Community zu uninteressanten Dingen. Bin es gewohnt, fast kein Feedback zu bekommen. (mimimi!) Schade eigentlich, in meinen Augen weitaus nützlichere Dinge als nen 64bit Compiler... Vor allem, wenn es darum geht, moderne Software Entwicklung zu betreiben. Der nächste "Delphi ist am Ende"-Thread steht bestimmt schon in den Startlöchern - kein Wunder

Zitat von stahli:

PS: Wie (ungefähr) regelt eigentlich die IDE selbst die Bearbeitung von Objekteigenschaften im Objektinspektor? Da muss ja eine ähnliche Bindung realisiert sein? Kann das jemand grob erklären?

Das geschieht über die published Properties der Objekte. Genau dafür wird die schon vor Delphi 2010 vorhandene RTTI benutzt.

P.S.: Die von mir angeschnittenen Projekte und noch einiges andere sind Teil eines größeren MVVM Prototypens - natürlich auch fein bei .Net (inklusive diversen Codeplex Projekten) gespickt - die liefern halt gute Vorlagen.

[Elvis]

Zitat von Stevie:

da haperts aber für die Generierung von vernünftigen SQL Statements (abgesehen von nem full table select) noch etwas. Vor allem Mangels ExpressionTrees der delegates, die in .Net "einfach" in SQL umgebaut werden. Bisher gehen einfache Abfragen aber komplette Codegenerierung für Datenklassen über Metadaten aus nem SQL Server Datenbank Schema ist bereits implementiert.

Wenn du dort auch nur ansatzweise irgendwohin kommen willst, mussu den Ansatz, den du da gerade hast wegwerfen.
Wenn du wissen willst, was wie gefiltert wird, könntest du IDispatch-Implementierungen bauen, die vom User als OleVariant benutzt werden (aka C# dynamic).
Auf die Art solltest du alle Calls abgreifen können. Du musst halt immer nach jeder Operation ein neues IDispatch zurückgegeben, welches alle vorher aufgezeichneten Operation kennt.

Habe Delphis komische Syntax für Lambdas nicht im Kopf, aber stelle dir eine extension method vor, die Delphis Gegenstück zu Func<OleVariant, Boolean> schluckt.
Der OleVariant, der dort übergeben wird, wäre also nicht das jeweilige Item der Liste. Nope, du würdest die anonym. Method sofort ausführen, da DEIN OleVariant ja alle auf ihn angewandten Operationen aufzeichnet.

Delphi-Quellcode:

YourTable.Where(function(row : OleVariant) : Boolean;
begin
  exit((row.SomeColumn = 1) and (row.SomeOtherColumn <> 'Test' );
end).Select(procedure(const row, result : OleVariant);
begin
  result.ResultField1 := row.Field1;
  result.Abc := 1;
  result.Def := row.Field2;
end);

Code:

SELECT t.Field2 as ResultField1, 1 as Abc, t.Field2 as Def 
from ... 
where t.SomeColumn = 1 and t.SomeOtherColumn <> 'Test'

Die Where Clause:
OleVariant (OV) 1: Ergebnis von row.SomeColumn
OV 2: Ergebnis von OV1 = 1
OV 3: Ergebnis von row.SomeOtherColumn
OV 4: Ergebnis von OV3 <> 'Test'
OV 5: Ergebnis von OV2 and OV4

Sollte IMHO möglich sein.
Natürlich gehen auf der Basis noch ganz andere Sachen, für die in .Net ExpressionTrees benutzt werden. (Mocking Setups!)

Aber mache all das nur solange es dir wirklich Spass macht. Du kannst Delphi nicht in etwas Modernes verwandeln.
Jede dieser Lösung wird einen schalen Beigeschmack haben, und dem Dev, der es einsetzt wird dabei ständig ein kleines Männchen dezent mit einem Holzhammer von innen an die Schädeldecke schlagen um dabei unaufhörlich "HACK! HACK!" brüllen....

[Stevie]

Zitat von Elvis:

Zitat von Stevie:

da haperts aber für die Generierung von vernünftigen SQL Statements (abgesehen von nem full table select) noch etwas. Vor allem Mangels ExpressionTrees der delegates, die in .Net "einfach" in SQL umgebaut werden. Bisher gehen einfache Abfragen aber komplette Codegenerierung für Datenklassen über Metadaten aus nem SQL Server Datenbank Schema ist bereits implementiert.

Wenn du dort auch nur ansatzweise irgendwohin kommen willst, mussu den Ansatz, den du da gerade hast wegwerfen.

Ich frag mich, woher du weißt, welchen Ansatz ich verfolge.

Zitat von Elvis:

Wenn du wissen willst, was wie gefiltert wird, könntest du IDispatch-Implementierungen bauen, die vom User als OleVariant benutzt werden (aka C# dynamic).
Auf die Art solltest du alle Calls abgreifen können. Du musst halt immer nach jeder Operation ein neues IDispatch zurückgegeben, welches alle vorher aufgezeichneten Operation kennt.

Habe Delphis komische Syntax für Lambdas nicht im Kopf, aber stelle dir eine extension method vor, die Delphis Gegenstück zu Func<OleVariant, Boolean> schluckt.
Der OleVariant, der dort übergeben wird, wäre also nicht das jeweilige Item der Liste. Nope, du würdest die anonym. Method sofort ausführen, da DEIN OleVariant ja alle auf ihn angewandten Operationen aufzeichnet.

Delphi-Quellcode:

YourTable.Where(function(row : OleVariant) : Boolean;
begin
  exit((row.SomeColumn = 1) and (row.SomeOtherColumn <> 'Test' );
end);

OleVariant (OV) 1: Ergebnis von row.SomeColumn
OV 2: Ergebnis von OV1 = 1
OV 3: Ergebnis von row.SomeOtherColumn
OV 4: Ergebnis von OV3 <> 'Test'
OV 5: Ergebnis von OV2 and OV4

Sollte IMHO möglich sein.
Natürlich gehen auf der Basis noch ganz andere Sachen, für die in .Net ExpressionTrees benutzt werden. (Mocking Setups!)

Ich habe in den letzten Tagen bereits mit einer Mischung aus Records/operator overloading und Invokable variant types herum experimentiert und war in der Tat in der Lage unäre und binäre Expressions sowohl in ihre String Repräsentationen umzuwandeln, als auch sie auszuwerten. Aber danke für den Hinweis mit den OleVariants. Werde ich mir mal anschauen.

Edit: Hast du eventuell ein kleines Beispiel, ob und wie ich die Operatoren für nen OleVariant überschreiben kann?
Edit2: Hab was gefunden in der Unit VarCmplx.pas (die seh ich heute zum ersten mal in meinem Leben )

Zitat von Elvis:

Aber mache all das nur solange es dir wirklich Spass macht. Du kannst Delphi nicht in etwas Modernes verwandeln.
Jede dieser Lösung wird einen schalen Beigeschmack haben, und dem Dev, der es einsetzt wird dabei ständig ein kleines Männchen dezent mit einem Holzhammer von innen an die Schädeldecke schlagen um dabei unaufhörlich "HACK! HACK!" brüllen....

Ich will den Thread hier nicht in eine weitere Diskussion zu diesem Thema ausarten lassen, denn ich bin dessen überdrüssig. Nur soviel: eine Programmiersprache ist bis zu einem gewissen Grad nur so modern, wie die Programmierer, die sie nutzen. [ironie]Wenn die Mehrzahl der Delphianer immernoch in ihren Höhlen hausen wollen und mit Delphi 7 Software Praktiken aus dem letzten Jahrtausend praktizieren, bitte[/ironie]. Ich nutze gerne alle Möglichkeiten, die sich mir bieten, um auch das letzte aus der Sprache herauszubekommen, auch wenn ich bloß zu nem VS2010 (Express) greifen müsste, und gleich alles serviert bekomme. Aber wo bliebe da der Spaß?

[Domo Sokrat]

Hi Stevie,

ich find's prima, dass sich jemand drum kümmert, Delphi ein wenig moderner zu machen und innovative Konzepte, wie z. B. das WPF-Databinding von .NET in Abwandlung nach Delphi zu portieren (INotifyPropertyChanged find' ich übrigens klasse , obwohl's manchmal nervt).

Und: Ja, .NET-Entwickler haben (manchmal auch) innovative Konzepte, die sich durchsetzen! Wieso also diese nicht umsetzen, wenn man die Möglichkeiten hat? Seinerzeit wurden die Zeos-Komponenten ja auch aus der Java-Welt portiert ...

Und: Ja, D7 ist Steinzeit - Ich merk's jedes Mal wieder! So! Mehr sach' ich nicht dazu

Grüße und weiter so

M.

[Stevie]

Ich hab den Data Bindings nun ein Designtime Package verpasst, so dass man sie mit dem Objektinspector editieren kann.

[RWarnecke]

Hallo Stevie,

ich probiere gerade Dein Data Bindings aus. stahli hat mich hier darauf aufmerksam gemacht, dass das Data Bindding vielleicht etwas für mich wäre. Ich habe aber ein Problem mit der folgenden Procedure :

Delphi-Quellcode:

procedure TBindingGroup.WriteBindings(AWriter: TWriter);
var
  LAncestor: TPersistent;
  LBinding: TBindingBase;
begin
  LAncestor := AWriter.Ancestor;
  AWriter.Ancestor := nil;
  try
    TWriterHack(AWriter).WriteValue(vaCollection);
    for LBinding in FBindings do
    begin
      AWriter.WriteListBegin();
      AWriter.WriteProperties(LBinding);
      AWriter.WriteListEnd();
    end;
    AWriter.WriteListEnd();
  finally
    AWriter.Ancestor := LAncestor;
  end;
end;

Und zwar mit der Zeile AWriter.WriteProperties(LBinding); . Hier spuckt mir der Compiler die Fehlermeldung [DCC Error] System.Bindings.pas(684): E2362 Cannot access protected symbol TWriter.WriteProperties aus. Diese Meldung bekomme ich, wenn ich das Designtime-Package unter Delphi 2010 lade und installieren möchte und wenn ich die Datei System.Bindings.pas manuell einbinde. Mache ich hier etwas falsch oder habe ich etwas vergessen.

[Stevie]

Die Version im Post oben ist etwas veraltet Hol dir einfach die aktuellste Version aus dem svn. Ich werde aber im Laufe des Wochenendes eine aktuelle Version hier hochladen.

Edit: Aktuelle Archive hochgeladen