DSharp - Data bindings, MVVM und mehr für Delphi 2010 und höher

[Stevie]

Da das Thema DSharp nun doch des öfteren in diversen Threads auftaucht und dort dann oft bezüglich des eigentlichen Themas des Threads doch eher OT ist, mach ich hier mal den "offiziellen DP DSharp Diskussions Thread" auf ;)

Was ist eigentlich DSharp?

Das D im Namen kommt natürlich von Delphi und das Sharp daher, da viele Konzepte aus der C# Welt stammen - und da die .Net Sprache von Embarcadero Prism heißt, war das noch nicht anderweitig belegt ;)

Einen Großteil von DSharp macht das DataBinding aus. Ähnlich wie LiveBindings aber nicht so komplex und auf die Kernfunktionalitäten konzentriert. Und schon ab Delphi 2010 lauffähig - mit einigen wenigen Ausnahmen. Darauf aufbauend ist ein MVVM Framework (gerade im Aufbau) enthalten, was Entwickler dabei unterstützen soll, auf einfachem Wege hochmodulare GUI Anwendungen zu schreiben, die durch ihre entkoppelten Teile eine hohe Wartbarkeit und Testbarkeit haben. Dabei wird der DI Container von spring4d genutzt. Andere Teile von DSharp stellen AOP (über Proxies für Interfaces und Patchen der VMT für virtuelle Methoden) und Mocks bereit.

[mquadrat]

Na da diskutier ich doch mit. Ist die MVVM Implementierung an eines der .NET MVVM Frameworks angelehnt? Wenn ja an welches? Ich finde ja Caliburn.Micro interessant.

EDIT: Nevermind, gerade den anderen Thread gelesen :D


Zweite Frage: Warum spring4d als IOC-Container? Hattest du nicht eine MEF-Portierung in Arbeit? Kann man ja auch für IOC verwenden.

[Stevie]

Der Spring DI Container ist weiterentwickelt, als der MEF Prototyp (der ja auch nicht von mir selbst entwickelt war, sondern den ich nur etwas modifiziert hatte).

Daher habe ich mich entschieden, diesen zu verwenden, da er alle Features hat, die ich benötige (die Sache mit dem Rad neu erfinden und so)
Die Schnittstelle von DSharp (der TSpringContainer) stellt genau die Funktionalität bereit, die auch der MEF Prototyp hatte (Import/ Export Attribute, Lazy initialization)

[mquadrat]

Macht Sinn. Wenn es über einen Adapter läuft umso besser. Ich bin bei Spring4D aktuell noch nicht so sicher, wo bei denen die Reise hin geht. Ich hoffe mal, ich habe zwischen den Jahren Zeit mich da mal wieder umfassend drum zu kümmern. Aktuell läuft mal wieder die "Ich habe noch Budget gefunden, das weg muss" Rally :lol:

[BlackSeven]

Es kommt zu einer Zugriffsverletzung, wenn folgender Eventhandler hinzugefügt wird:

TEventTest = procedure(const AInterface: IInterface; var AKey: Word; var AKeyChar: WideChar; AShift: TShiftState) of object;

Delphi-Quellcode:

type

  TEventTest = procedure(const AInterface: IInterface; var AKey: Word; var AKeyChar: WideChar; AShift: TShiftState) of object;

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private

    _EventTest : TEvent<TEventTest>;

    procedure ProcessEventTest(const AInterface: IInterface; var AKey: Word; var AKeyChar: WideChar; AShift: TShiftState);

  public

  end;

var
  Form1: TForm1;

implementation


{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var

  Key     : Word;
  KeyChar : WideChar;

begin

  _EventTest.EventHandler.Add(Self.ProcessEventTest);

  Key     := 0;
  KeyChar := 'K';

  _EventTest.Invoke(nil, Key, KeyChar, []);

end;

procedure TForm1.ProcessEventTest(const AInterface: IInterface; var AKey: Word; var AKeyChar: WideChar; AShift: TShiftState);
begin

end;

Fehler tritt in Unit DSharp.Core.Events.pas in Zeile 247 auf:

Delphi-Quellcode:

  TValue.Make(Pointer(PNativeInt(@Params.Stack[LOffset])^),
    FParameters[i].ParamType.Handle, LArgs[i + 1]);

[Stevie]

Mannomann, da haste mich aber kalt erwischt - ich hasse dieses Stack und Registergefrickel. :oops:
Keine Ahnung, warum ich die Parameter auf dem Stack falsch herum durchgegangen bin.

Fixed in r242

P.S.:
Unter XE und eher wird das übrigens vor die Wand klatschen.
Fälschlicherweise wird dort in der ObjAuto.pas für Sets eine Größe von -1 zurückgeliefert und daher stimmt die Stacksize nicht.
Das kann man durch ein const vor dem Set Parameter lösen. In XE2 ist dieser Bug behoben.

[BlackSeven]

Zitat:

ich hasse dieses Stack und Registergefrickel

Ich auch.

Danke für die schnelle Fehlerbereinigung. :thumb:

[Stevie]

Zitat:

Zitat von Stevie (Beitrag 1137375)

Unter XE und eher wird das übrigens vor die Wand klatschen.
Fälschlicherweise wird dort in der ObjAuto.pas für Sets eine Größe von -1 zurückgeliefert und daher stimmt die Stacksize nicht.
Das kann man durch ein const vor dem Set Parameter lösen. In XE2 ist dieser Bug behoben.

Dank Andreas wird jetzt die entsprechende Routine für 2010 und XE zur Laufzeit gepatcht, so dass dieser Fehler nicht mehr auftritt.

[Jens01]

Hallo Stevie,

habe gerade versucht Deine neuste Version zu compilieren, aber es kam der Fehler E2010 in DSharp.Bindings Zeile 305:

Delphi-Quellcode:

if TryGetRttiType(AComponent.ClassInfo, LType) and (LType.IsInheritedFrom('TForm')<- hier
    or LType.IsInheritedFrom('TFrame') or LType.IsInheritedFrom('TDataModule')) then
  begin
    LOwner := AComponent;
  end

Ich nutze XE2 mit dem 2. Update.
Liegt das an mir oder gibt es einen Fehler?

Gruss Jens

[Stevie]

Ich wüsste spontan nicht, was an dieser Zeile einen Fehler bringen sollte. Stelle bitte sicher, dass alle Source Dateien auf dem aktuellen Stand sind. Bei einem Update empfielt es sich außerdem, die dcu Dateien im Libraries\<Delphi Version> Ordner zu löschen (manuell oder über das Ausführen der clean.bat) und alle Packages zu builden und nicht nur kompilieren. Im Normalfall sollte aber ein Öffnen der BuildPackages.groupproj und ein Build all genügen.

Sollte der Fehler dann noch bestehen, bitte mal die komplette Meldung posten, E2010 sagt mir nur, inkompatible Typen, aber nich welche Stelle genau innerhalb dieser Zeile.

[Jens01]

habe clean.bat gemacht und der Fehler kommt hier :

Delphi-Quellcode:

and (LType.IsInheritedFrom('TForm')

Zitat:

[DCC Fehler] DSharp.Bindings.pas(305): E2010 Inkompatible Typen: 'TRttiType' und 'string'
[DCC Fehler] DSharp.Bindings.pas(306): E2010 Inkompatible Typen: 'TRttiType' und 'string'
[DCC Fehler] DSharp.Bindings.pas(306): E2010 Inkompatible Typen: 'TRttiType' und 'string'

[Stevie]

IsInherited ist eine 2fach überladene Methode des TRttiType class helpers in the DSharp.Core.Reflection. Auf die Gefahr hin, mich zu wiederholen: stelle bitte sicher, dass du auch das DSharp.Core Package neu kompiliert hast und nicht irgendwo noch eine alte Version davon liegen hast. Der Fehler deutet darauf hin, dass die Überladung der Methode, welche ich am 6. November (r204) hinzugefügt habe, nicht gefunden wird.

[Jens01]

Sorry, sorry....mein Fehler.
Aus irgendeinem Grund wurden nicht alle Dateien runtergeladen bzw aktualisiert.
Ich habe alles noch mal neu runtergeladen und es läuft!

Wenn ich Dich mal treffe, gebe ich nen Bier aus, okay?

[Stevie]

Zitat:

Zitat von Jens01 (Beitrag 1139100)

Sorry, sorry....mein Fehler.
Aus irgendeinem Grund wurden nicht alle Dateien runtergeladen bzw aktualisiert.
Ich habe alles noch mal neu runtergeladen und es läuft!

Wenn ich Dich mal treffe, gebe ich nen Bier aus, okay?

Ist doch kein Problem, dafür ist der Thread ja da - und jau, gute Idee :cheers:

[stahli]

Nachdem ich beim ersten Versuch wegen diverser Probleme gescheitert bin habe ich heute in einem Testsystem noch einen weiteren Versuch unternommen (XE Prof).
Mein GData hat wieder angeschlagen. Da ich mit einem Testsystem arbeite, habe ich das mal ignoriert.


Hier meine Schritte und Probleme, falls jemand allein auch nicht zurande kam:

Ich habe folgende Ordner angelegt:

Projekte\DSharp
.\DelphiSorcery
.\DelphiSpring
.\VST

Dann TortoiseSVN installieren und für die o.g. Ordner über Rechtsklick/SVN Checkout die Projektdaten laden:
DelphiSorcery -> http://delphisorcery.googlecode.com/svn/trunk/
DelphiSpring -> http://delphi-spring-framework.googl...com/svn/trunk/
VST -> http://virtual-treeview.googlecode.com/svn/trunk/

Dann die Projekte erzeugen:


VST
===

Package erzeugen
C:\Users\as\Projekte\DSharp\vst\Packages\Delphi XE\VirtualTreesR.dproj

Bibliothekspfad hinzufügen:
C:\Users\as\Projekte\DSharp\vst\Common

Packages installieren
C:\Users\as\Projekte\DSharp\vst\Packages\Delphi XE\VirtualTreesD.dproj


DelphiSpring
============

Package erzeugen
C:\Users\as\Projekte\DSharp\delphispring\Packages\ DelphiXE\Spring.System.dproj
[DCC Warnung] Spring.System.dpk(50): W1006 Unit 'Spring.Reflection.ValueExpression' ist veraltet

Package erzeugen
C:\Users\as\Projekte\DSharp\delphispring\Packages\ DelphiXE\Spring.Core.dproj
[DCC Warnung] Spring.Core.dpk(35): W1007 Unit 'Spring.Configuration.ConfigurationProperty' ist experimentell
[DCC Warnung] Spring.Core.dpk(36): W1007 Unit 'Spring.Configuration.Node' ist experimentell
[DCC Warnung] Spring.Core.dpk(37): W1007 Unit 'Spring.Configuration' ist experimentell
[DCC Warnung] Spring.Core.dpk(39): W1007 Unit 'Spring.Configuration.Sources' ist experimentell
[DCC Warnung] Spring.Logging.LoggerManager.pas(39): W1007 Unit 'Spring.Configuration' ist experimentell

Ausführen
C:\Users\as\Projekte\DSharp\delphispring\Tests\Spr ing.Tests.dproj
[DCC Warnung] Spring.Tests.Reflection.pas(108): W1006 Unit 'Spring.Reflection.ValueExpression' ist veraltet
[DCC Warnung] Spring.Tests.Configuration.pas(32): W1007 Unit 'Spring.Configuration' ist experimentell
[DCC Warnung] Spring.Tests.Configuration.pas(53): W1007 Unit 'Spring.Configuration.Node' ist experimentell
[DCC Warnung] Spring.Tests.Configuration.pas(54): W1007 Unit 'Spring.Configuration.Sources' ist experimentell
[DCC Warnung] Spring.Tests.Configuration.pas(55): W1007 Unit 'Spring.Configuration.ConfigurationProperty' ist experimentell
[DCC Warnung] Spring.Tests.Logging.pas(7): W1007 Unit 'Spring.Configuration' ist experimentell
[DCC Warnung] Spring.Tests.Logging.pas(8): W1007 Unit 'Spring.Configuration.Sources' ist experimentell
[DCC Warnung] Spring.Logging.LoggerManager.pas(39): W1007 Unit 'Spring.Configuration' ist experimentell


DelphiSorcery
=============

Alle Packages erzeugen

Package installieren
C:\Users\as\Projekte\DSharp\delphisorcery\Packages \DelphiXE\dclDataBindings.dproj
C:\Users\as\Projekte\DSharp\delphisorcery\Packages \DelphiXE\dclDataBindingsVCL.dproj
C:\Users\as\Projekte\DSharp\delphisorcery\Packages \DelphiXE\dclTreeViewPresenter.dproj


=> Sampels\MVVM\Calculator

Bibliothekspfad hinzufügen:
C:\Users\as\Projekte\DSharp\delphispring\Library\D elphiXE\Debug

... OK


=> Sampels\MVVM\Explorer

Bibliothekspfad hinzufügen:
C:\Users\as\Projekte\DSharp\delphisorcery\Samples\ MVVM\Calculator\Debug\Win32

... [DCC Fataler Fehler] DSharp.Core.RegularExpressions.pas(93): F2051 Unit DSharp.Aspects.Weaver wurde mit einer unterschiedlichen Version von DSharp.Core.Reflection.TRttiTypeHelper.GetAttribut esOfType compiliert


=> Sampels\MVVM\ContactManager

Bibliothekspfad hinzufügen:
C:\Users\as\Projekte\DSharp\vst\Source


Fazit:
~~~~~~

Grundsätzlich hat die Installation so funktioniert.
Besonders hat mich (natürlich) das MVVM interessiert.
Die Beispiele muss ich mir noch in Ruhe anschauen. Der Explorer ließ sich jedoch nicht erzeugen.
Auf den ersten Blick konnte ich nicht nachvollziehen, wieviel Arbeit das Framework einem wirklich erspart - wie es also für das Erstellen eines neuen Projektes letztlich eingesetzt wird.
Hat man wirklich deutlich weniger Arbeit dadurch?

Soweit mein erster Eindruck. Mir fehlt noch etwas der Zugang. Ich muss mir dafür nochmal die Zeit nehmen.

Ein Video (notfalls auch in englisch) wäre m.E. ganz nett... ;-)

[Stevie]

Ich hab gestern einen neuen Blog Artikel zum MVVM veröffentlicht, in dem ich zeige, wie man eine simple Anwendung nach diesem Modell erstellt. Wie ich auch dort erwähne ist der Stand dieses Teils von DSharp zugegebenerweise noch in einem frühen Stadium, was den Einsatz in komplexen und verschachtelten Anwendungen angeht, vor allem, wenn man verschiedene GUI Teile auf selber Ebene hat (das Explorer Sample ist work in progress, wo ich diesen Ansatz weiter verfolge). Aber man kann schon gut eine Idee bekommen, wohin es führen soll und was damit erreicht werden kann.

Eine Sache noch - um Verwirrung zu vermeiden: die Library heißt DSharp, mein Blog Delphi Sorcery. Zum Zeitpunkt als ich das repository auf google code angelegt habe, gab es den Namen DSharp für die Lib noch nicht, daher hab ich es unter dem Namen des Blogs veröffentlicht - leider kann man nach wie vor nicht einfach das Projekt umbenennen oder einfach umziehen; daher lass ich es erstmal so.

[mquadrat]

Gerade mal den Blog-Post gelesen:

Vielleicht liegt es einfach dran, dass Montag ist, aber würde es nicht langen ein ViewModel-Interface im Framework mit zu liefern, anstatt jedes Mal ein eigenes leeres Interface zu deklarieren? Für den Fall, dass man ein nicht-leeres Interface verwenden möchte, kann man dann ja immernoch ein eigenes nehmen, oder?

PS: Ich bezieh mich da gerade auf das ICalculatorViewModel aus dem Beispiel.

[Stevie]

Und was soll der DI Container dann zurückliefern, wenn ein Resolve<IViewModel> aufgerufen wird, welches von 2 komplett unterschiedlichen ViewModel Klassen implementiert wurde, weil man kein eigenes Interface (leer oder nicht) deklariert hat?

[mquadrat]

:wall:

Ich sollte Montags einfach nichts posten :D


Naja, also streng genommen könnte man über alle Implementierungen des Interfaces iterieren und über die Namens-Konventionen gehen.

Disclaimer: Es ist immernoch Montag.

[Stevie]

Möglich wäre das, aber das würde einen größeren Eingriff in die Funktionsweise des DI Containers erfordern. Und das nur, um sich nen 3-Zeiler zu sparen für den Fall, dass man ebend in dem Interface für das ViewModel keine Methoden und/oder Eigenschaften hat, halte ich für keinen guten Weg.

Ich denke, deine Frage zielte auf etwas anderes:
Es spricht nichts dagegen, komplett auf das Interface zu verzichten in diesem simplen Fall. Im Calculator Beispiel würde das dann bedeuten, du schreibst einfach

Delphi-Quellcode:

Application.Start<TCalculatorViewModel>;

Die Registrierung der Klasse passiert in diesem Fall durch das [InheritedExport] auf TViewModelBase.

Wenn du dir das ContactManager Sample anschaust, wirst du aber sehen, warum das Interface in weniger trivialen Anwendungen fast unverzichtbar ist. Dort hast du nämlich die Kontaktübersicht, welche als Abhängigkeit die Kontaktdetails hat (weil es sie ja aufrufen muss). Wäre dort kein Interface für die Details vorhanden, hättest du eine Abhängigkeit dieser 2 Models. Mit dem Interface kannst du einfach das DetailViewModel ausmocken und die Übersicht testen.

[BlackSeven]

Habe gerade festgestellt, dass die DSharp-Multicast Events nun auch anonyme Methoden unterstützen.


:thumb:

[BlackSeven]

Hallo Stevie!

Ich bekomme folgenden Fehler, wenn ich ein Multicast Event in einem Multicast Event auslöse. Dieser Fehler tritt nur bei anonymen Methoden und nicht bei Methodenzeigern auf.

Exception: First chance exception at $746C23CC. Exception class $C0000092 with message 'floating point stack check at 0x746c23cc'. Process Project1.exe (2052)

Delphi-Quellcode:

  {$M+}
  TEventTest = reference to procedure;
  {$M-}

  TForm1 = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    procedure Button1Click(Sender: TObject);
  private

    _EventTest1 : Event<TEventTest>;
    _EventTest2 : Event<TEventTest>;

    procedure ProcessEventTest1;
    procedure ProcessEventTest2;

    function GeteventTest1: Event<TEventTest>;
    function GeteventTest2: Event<TEventTest>;

    property EventTest1: Event<TEventtest> read GetEventTest1;
    property EventTest2: Event<TEventtest> read GetEventTest2;

  public
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin

  Self.EventTest1.Add(Self.ProcessEventTest1);
  Self.EventTest2.Add(Self.ProcessEventTest2);

  _EventTest1.Invoke();

end;

procedure TForm1.ProcessEventTest1;
begin

  _EventTest2.Invoke(); <- hier 

end;

procedure TForm1.ProcessEventTest2;
begin
//
end;

function TForm1.GetEventTest1: Event<TEventTest>;
begin

  Result := _EventTest1.EventHandler;

end;

function TForm1.GetEventTest2: Event<TEventTest>;
begin

  Result := _EventTest2.EventHandler;

end;

end.

[Stevie]

Fix commited - ich hätte auf Arnaud hören sollen. ;)

Ein Hinweis noch: Du solltest event properties immer als IEvent<T> definieren.

[BlackSeven]

Zitat:

Ein Hinweis noch: Du solltest event properties immer als IEvent<T> definieren.

OK. Danke.

[pHL]

Hallo,

Ich habe mir gerade das VirtualTreeViewSample von DSharp angeschaut und wollte etwas ähnliches mit einem TcxGrid von DevExpress nachbauen.
Daher meine Frage: Funktioniert der GridViewPresenter noch nicht oder habe ich die Units einfach nicht richtig eingebunden? Ich bekomme beim
Kompilieren nämlich einen Fehler dass cxTL nicht gefunden wird.

Mfg.
pHL

[Stevie]

Zitat:

Zitat von pHL (Beitrag 1172473)

Ich habe mir gerade das VirtualTreeViewSample von DSharp angeschaut und wollte etwas ähnliches mit einem TcxGrid von DevExpress nachbauen.
Daher meine Frage: Funktioniert der GridViewPresenter noch nicht oder habe ich die Units einfach nicht richtig eingebunden? Ich bekomme beim
Kompilieren nämlich einen Fehler dass cxTL nicht gefunden wird.

Vermutlich hast du nur das Quantum Grid und nicht die Quantum TreeList von DevExpress?

In dem Fall, schmeiß die DSharp.DevExpress.TreeListPresenter.pas aus dem Package und passe die DSharp.DevExpress.Designtime.pas entsprechend an.

Edit: Auch die cxTreeList aus der requires des Packages nehmen.

[pHL]

Danke schonmal, ich habe einen TcxTreeView, keine Ahnung ob das nun zur Quantum Treelist gehört :D habe die Komponenten
noch nicht lange. Ansonsten mache ich es so.

Sollte der GridViewPresenter eine visuelle Komponente sein? Wenn ja dann habe ich einen Fehler beim installieren gemacht.

Mfg.

[Stevie]

Zitat:

Zitat von pHL (Beitrag 1172518)

Danke schonmal, ich habe einen TcxTreeView, keine Ahnung ob das nun zur Quantum Treelist gehört :D habe die Komponenten
noch nicht lange. Ansonsten mache ich es so.

Sollte der GridViewPresenter eine visuelle Komponente sein? Wenn ja dann habe ich einen Fehler beim installieren gemacht.

Mfg.

TcxTreeView ist der "Standard" Treeview, TcxTreeList ist eher sowas wie der Virtual Treeview. Wenn du die VCL Subscription oder das ExpressGridPack hast, dann ist das dabei, beim ExpressQuantumPack nicht.

Aber ich sehe gerade, dass ich das Package mit den DevExpress Presentern gar nicht commited habe :lol: Werd ich morgen mal machen

[pHL]

Alles klar :) dankeschön, dann passe ich das Package an dann sollts laufen.

Mfg.
pHL

[BlackSeven]

Hallo Stefan,

folgender Code löst eine Exception aus:

Delphi-Quellcode:

type

  {$M+}
  TEventTest = reference to procedure(const AValue: Int64);
  {$M-}

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    _EventTest : Event<TEventTest>;
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin

  _EventTest.EventHandler.Add
  (

    procedure(const AValue: Int64)
    begin

      ShowMessage(IntToStr(AValue));

    end

  );

  _EventTest.EventHandler.Invoke(1);

end;

Das Problem liegt an Int64.

Zitat:

TEventTest = reference to procedure(const AValue: Int64);

Mit Int32 funktioniert das Ganze.

[Stevie]

Danke für deinen Report.

Hier treffen leider 2 Bugs zusammen:
Der eine liegt in der ObjAuto.pas begründet. Dort wird nicht berücksichtigt, dass Int64 besonders behandelt wird.
Daran kann ich nicht sehr viel machen. Inzwischen werden schon genug Bugs durch Runtime Patching ausgebügelt.

Der zweite Bug liegt in meiner Implementierung ab XE2 (auch ich hab nicht auf die Int64 Sonderbehandlung unter x86 geachtet) und kommt ungeachtet des consts oder nicht. Dies werde ich sobald wie möglich beheben.

Soll heißen: Int64 und const wird nicht funktionieren, ohne const bis XE ja, ab XE2 (32-bit) nachdem ich es gefixt habe.

[BlackSeven]

Alles klar. Danke für die Info.

[BlackSeven]

Um nochmals auf DSharp und speziell auf MVVM zurückzukommen, werfe ich mal folgende Frage in den Raum:

Auf einer Form befindet sich eine Paintbox und ich möchte auf die "OnPaint" sowie "OnMouseMove" Ereignisse reagieren bzw. auf das Canvas zugreifen.
Löse ich das über einen speziellen "Presenter" oder wie ist dabei die beste Herangehensweise?

[BlackSeven]

Ich schätze mal, für die Behandlung von Events müssen in DSharp "Commands" implementiert werden.
Oder sehe ich das falsch?

[BlackSeven]

Hallo Stefan,

folgender, unter DXE2 (Zielplatform: Win64) kompilierter Code löst eine Exception aus:
First chance exception at $0000000000686EE1. Exception class $C0000005 with message 'c0000005 ACCESS_VIOLATION'. Process Project1.exe

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure FormCreate(Sender: TObject);
  private

    FClick: TNotifyEvent;

    function GetClick: TNotifyEvent;
    procedure SetClick(const AValue: TNotifyEvent);

  public

    property Click: TNotifyEvent read GetClick write SetClick;

  end;

var
  Form1: TForm1;

implementation

uses

  DSharp.Bindings;

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin

  TBinding.Create(Button1, 'OnClick', Self, 'Click');

end;

function TForm1.GetClick: TNotifyEvent;
begin

  Result := FClick;

end;

procedure TForm1.SetClick(const AValue: TNotifyEvent);
begin

  FClick := AValue;

end;

end.

Der Fehler tritt in der Unit "DSharp.Core.Expressions" auf:

Delphi-Quellcode:

procedure TPropertyExpression.SetValue(const Value: TValue);
var

...

begin

...

  if FIndex = -1 then
  begin
    
    if LProperty.IsWritable then
    begin
      LProperty.SetValue(LInstance.AsPointer, LValue); <--- hier
    end;

  end

...

System.Rtti.Invoke -> RawInvoke(CodeAddress, @block);

[Stevie]

Kurze Rückmeldung zu diesem Bug.

Mal wieder ein Fehler in Delphi - dort werden unter x64 bei Methodenaufrufen Parameter vom Typ tkMethod falsch behandelt (auch in XE3 noch existent).

Auch ohne DSharp nachstellbar:

Delphi-Quellcode:

var
  ctx: TRttiContext;
begin
  ctx.GetType(TForm1).GetMethod('SetClick').Invoke(Self, [TValue.From<TNotifyEvent>(Button1Click)]);
end

Mal sehen, ob ich das patchen kann.

[Codewalker]

@Stevie: Gibt es irgendwo ein Tutorial bzw. eine Übersicht was du alles eingebaut hast und was so alles geht? Ich nutze (bisher) wahrscheinlich nur 0,1% (eigentlich nur IEvent<T>) von DSharp

[Jens01]

Zitat:

Zitat von Codewalker (Beitrag 1199999)

@Stevie: Gibt es irgendwo ein Tutorial bzw. eine Übersicht was du alles eingebaut hast und was so alles geht? Ich nutze (bisher) wahrscheinlich nur 0,1% (eigentlich nur IEvent<T>) von DSharp

Guck einfach mal die Samples durch.

[Marco Erdmann]

Hallo Zusammen,

ich bin neu in diesem Forum und mache gerade meine ersten Gehversuche mit DSharp. Ich habe versucht das VirtualTree-Beispiel mit dem QuantumGrid von DevExpress nachzubauen und bin dabei auf ein Problem gestoßen: Die Spalten-Captions im Grid werden noch korrekt gesetzt, aber die Zeilen werden niemals angezeigt, obwohl die Anzahl Zeilen durchaus richtig abgefragt wird. Ich vermute, dass ich noch einen Fehler im Template habe. Die Delphi-Version ist XE3 Update 2 und das Grid ist ein TcxGridTableView.

Die Klasse in meiner IList sieht so aus:

Delphi-Quellcode:

  
TEmployee = class(TPersistent)
  private
    FFirstName: string;
    FID: Integer;
    FName: string;
  public
    constructor Create(AID: Integer; const AName, AFirstName: string);
    property FirstName: string read FFirstName write FFirstName;
    property ID: Integer read FID write FID;
    property Name: string read FName write FName;
  end;

Das TDataTemplate sieht dann foglendermaßen aus:

Delphi-Quellcode:

  
TEmployeeTemplate = class(TDataTemplate)
  public
    function GetValue(const Item: TObject; const ColumnIndex: Integer): TValue; override;
    function GetTemplateDataClass: TClass; override;
  end;

Delphi-Quellcode:

function TEmployeeTemplate.GetTemplateDataClass: TClass;
begin
  Result := TEmployee;
end;

function TEmployeeTemplate.GetValue(const Item: TObject; const ColumnIndex: Integer): TValue;
begin
  case ColumnIndex of
    (-1), 0: Result := TEmployee(Item).ID;
    1: Result := TEmployee(Item).Name;
    2: Result := TEmployee(Item).FirstName;
  end;
end;

Ich bin noch nicht soweit in den Code eingestiegen, um genau zu verstehen, an welcher Stelle die Sache schiefgeht. Muss ich eventuell weitere virtuelle Methoden von TDataTemplate überschreiben? Ein Fingerzeig in die richtige Richtung wäre sehr nett.

Vielen Dank schonmal.

[Stevie]

Hallo Marco,

ich denke, der Fallstrick wird gewesen sein, dass du das ItemTemplate direkt zugewiesen und somit das built-in DataTemplate überschrieben hast.
Dieses wird bei einem Presenter immer erstellt und beinhaltet die Standardimplementierungen für z.B. GetItemCount und GetItem.

Du musst somit die RegisterDataTemplate Methode nutzen, um dein Template für TEmployee dort zu nutzen:

Delphi-Quellcode:

GridViewPresenter1.View.ItemTemplate.RegisterDataTemplate(TEmployeeTemplate.Create);

Über diese Funktionalität kannst du unterschiedliche Templates in einem Presenter benutzen (wenn du z.B. eine Liste mit unterschiedlichen Klassen oder eine Hierarchie hast)