Data-Pointer in Interfacevariable casten

[RedOne]

Hallo zusammen
Die Delphi-Interfaces bringen mich gerade an den Rand der verzweiflung...

Ich habe folgenden Code:

Delphi-Quellcode:

var
  i: IDataObject;
begin
  if ListViewMain.ItemIndex >= 0 then begin
    i:= ListViewMain.Selected.Data as IDataObject;
    FillForm( i );
  end
end;

Im Data werden verschiedene Objekte abgelegt die alle dieses Interface implementieren.
Dieser Code gibt ein Compillerfehler (E2015 Operator ist auf diesen Operandentyp nicht anwendbar).
Caste ich mit IDataObject( ListViewMain.Selected.Data ) gibt es mir einen Laufzeitfehler (Data ist Assigned).

Wo liegt den hier das Problem?
Merci

[himitsu]

Ein Pointer ist halt kein Interface.

Delphi-Quellcode:

i := IDataObject(ListViewMain.Selected.Data);
// oder
i := Interface(ListViewMain.Selected.Data) as IDataObject;

PS: Wie regelst du denn die Referenzzählung?
Wenn keine andereren Referenzen auf das Interface bestehen und du dieses nicht beachtest, dann würde das Interface freigegeben, auch wenn du dieses hier verlinkt hast, falls du keine Referenz hierfür beantragst.

Delphi-Quellcode:

// zuweisen
ListViewMain.Selected.Data := Pointer(DataObject);
DataObject._AddRef;

// vorm freigeben 
DataObject.__Release;

[RedOne]

Merci für Deine Antwort.
Mit i:= IDataObject( ListViewMain.Selected.Data ); wird bei dieser Zeile eine Exception geworfen (Zugriffsverletzung) obwohl das Objekt existiert und auch instanziert ist (habs zur Sicherheit nochmals getestet).
Casten mit i:= Interface(ListViewMain.Selected.Data) as IDataObject; ergibt einen Compilerfehler...

Das Objekt (TAccountDataExtend) im Data implementiert eine weitere Klasse (TAccountData) und das Interface. TInterfacedObject implementiere ich schon auf der implementierten Klasse TAccountData. Ich nehme an, dies sollte schon funktionieren? Ein anderer Weg ist mir (bisher) noch nicht bekannt.

Delphi-Quellcode:

TAccountData = class( TInterfacedObject )[...]
TAccountDataExtend = class( TAccountData, IDataObject ) [...]

Die Frage betreffend der Referenzzählung ist gut
In Delphi habe ich bisher nicht das Glück gehabt mit Interfaces zu arbeiten. Da bin ich wohl ein bisschen .Net verwöhnt bei dem dies keine Rolle spielt

Herzlichen Dank
RedOne

[himitsu]

Ups, meinte natürlich IInterface
i:= IInterface(ListViewMain.Selected.Data) as IDataObject; .

Es sah allerdings so aus, als wenn das Interface direkt im .Data drin ist, bzw. es klang irgendwie danach.
Aber wenn es das Objekt ist, dann mußt du .Data natürlich in Diese casten.

i := TAccountDataExtend(ListViewMain.Selected.Data) as IDataObject;

[RedOne]

Das geht ja flux mit Antworten... Merci!

i:= IInterface(ListViewMain.Selected.Data) as IDataObject; compilliert zwar aber gibt immer noch einen Laufzeitfehler.
Gerne würde ich direkt in mein TAccountData casten, kann ich aber nicht:
Ich habe ein abstraktes Basisformular da alle Editierfenster den gleichen Aufbau besitzen.
Nun habe ich ein AccountForm davon abgeleitet. Dieses rufe ich auf und fülle beim Start eine Listview (auf Basisklasse vorhanden) mit meinen TAccountDataExtend's.
Wird ein Datensatz angeklickt und auf den Löschbutton geklickt, so wird auf Stufe des Basisformulares, dass keine Ahnung hat um was für ein Objekt es sich handelt, das Objekt im Data auf mein IDataObject-Interface gecastet und die Funktion "Delete" aufgerufen, die wegen dieses Interfaces auf meinem TAccountDataExtend implementiert sein muss.
Aber auf Stufe des Basisformulares weiss ich nicht was für ein konkretes Objekt sich in der Listview befindet. Allerdings weiss ich dass jedes Objekt die genannte "Delete"-Funktion implementiert, da diese ja von diesem Interface abgeleitet sind.

Wenn ich die Klasse für TAccountDataExtend zu Testzwecken auf Stufe des Basisformulars einbinde und caste sehe ich dass dieses Objekt existiert und kann auch die Deletefunktion aufrufen. Darum bin ich ein bisschen verwirrt wieso ich mein Data-Pointer nicht in dieses Interface casten kann, respektive wieso mir dieser Hund eine Exception wirft

Herzlichen Dank

Ps.
Einige Auszüge aus dem Code. Das beim "OnChange"-Ereignis gelöscht wird macht weniger Sinn. Dies ist mehr zum Verständnis

Delphi-Quellcode:

//-------- TFormEditBase 
TFormEditBase = class( TForm )
  procedure ListViewMainChange( _sender: TObject; _item: TListItem; _change: TItemChange );
  ...
end;

procedure TFormEditBase.ListViewMainChange( _sender: TObject; _item: TListItem; _change: TItemChange );
var
  i: IDataObject;
begin
  if ListViewMain.ItemIndex >= 0 then begin
    i:= IInterface(ListViewMain.Selected.Data) as IDataObject;
    i.Delete;
  end;
end {ListViewMainChange};

//-------- TFormAccounts 
TFormAccounts = class( TFormEditBase )
  procedure Load;
  ...
end;

procedure TFormAccounts.Load;
var
  tmp: TAccountDataExtend;
  obj: TObjectList;
  i: Integer;
  item: TListItem;
begin
  GetAllAccounts( obj );
  try
    for i:= 0 to obj.Count - 1 do begin
      tmp:= obj[ i ] as TAccountDataExtend;
      item:= ListViewMain.Items.Add;
      item.SubItems.Add( tmp.Name );
      item.Data:= tmp;
    end;
  finally
    obj.Free;
  end;
end;

[brechi]

Erstmal grundsätzlich: Speicher sollte dort freigegeben werden wo man diesen auch initialisiert hat

Delphi-Quellcode:

var
  obj: TObjectList;
begin
  obj := TObjectList.Create;
  try
    GetAllAccounts( obj );
    ...
  finally
    obj.Free;
  end;
end;

Dann zu deinem Problem:

1) warum verwendest du eine Objektlist wenn du mit Interfaces arbeitest? Gibt auch eine TInterfaceList
2) wenn du eine ObjectList verwendest, ist auch OwnsObjects auf false, sonst sind die Objekte beim Free alle wieder weg (auch deine TInterfaceObjects)

Bei Item.Data solltest du dann auch das Interface angeben und den Referenzcounter erhöhen. Hier mal ein Beispiel hoffe das ist jetzt so korrekt und du kannst was damit anfangen

Delphi-Quellcode:

type
  IIrgendwas = interface ['{0EF386E9-7F06-4D9A-A261-37D61BE3F8BE}']
    procedure MessageBox;
  end;

  TMyObject = class(TInterfacedObject, IIrgendwas)
    procedure MessageBox;
  end;

procedure TForm6.FormCreate(Sender: TObject);
var
  x: TInterfaceList;
  obj, obj2: IInterface;
  obj3: IIrgendwas;
  sl: TStringList;
  i: integer;
begin
  obj := TMyObject.Create;

  sl := TStringList.Create;
  try
    x := TInterfaceList.Create; // statt der ObjectList
    try
      x.Add(obj); 
      for i := 0 to x.Count - 1 do begin
        sl.Add('test');
        obj._AddRef; // ein cast als Pointer bekommt Delphi nicht mit (dein data)
        sl.Objects[i] := Pointer(obj);
      end;       
    finally
      FreeAndNil(x);
    end;

  obj := nil;

  // verwenden und freigeben
  obj2 := IInterface(Pointer(sl.Objects[0]));
  if Succeeded(obj2.QueryInterface(IIrgendwas, obj3)) then
    obj3.MessageBox;
  obj2._Release;
  finally
    FreeAndNil(sL);
  end;

end;

{ TMyObject }

procedure TMyObject.MessageBox;
begin
  MessageBoxA(0, 'test', nil, 0)
end;

[RedOne]

Merci für Deine Antwort. Wir kommen näher

Der Speicher wird vor der Funktion initialisiert. Ich habe den Code zusammengestrichen, da ist sie mir wohl abhanden gekommen

Zitat:

1) warum verwendest du eine Objektlist wenn du mit Interfaces arbeitest? Gibt auch eine TInterfaceList

Weil ich diese bisher nicht kannte

Zitat:

2) wenn du eine ObjectList verwendest, ist auch OwnsObjects auf false, sonst sind die Objekte beim Free alle wieder weg (auch deine TInterfaceObjects)

OwnsObject setzte ich bis anhin in der Funktion auf false

Ich habe das ganze jetzt mal gemäss Deinem Beispiel umgebaut und es funktioniert fast. Weder gibt es einen Compillier- noch einen Laufzeitfehler
In der Methode "Delete" gebe zu Testzwecken FID aus. Diese ist jedoch immer 0. Beim abfüllen beziehe ich den Text für die Listview direkt aus dem Objekt, die ID ist also beim Start definitiv gesetzt.

Verkürzter Code:

Delphi-Quellcode:

IDataObject = interface( IInterface )
  ['{C94DCAC7-CA42-45D3-95D7-9BC321BA2E2A}']
  procedure Delete;
end;

TAccountData = class( TInterfacedObject )
protected
  FID: Integer;
public
  property ID: Integer read FID write FID;
end;

TAccountDataExtend = class( TAccountData, IDataObject )
public
  procedure Delete;
end;

procedure TFormAccounts.Refresh;
var
  tmp: IInterface;
  i: Integer;
  item: TListItem;
  x: TInterfaceList;
begin   
  //Vorgängig Listview aufräumen, Objekte zerstören, Interface Releasen
         
  x:= TInterfaceList.Create;
  try
    GetAllAccounts( x ); //Siehe Funktion unten
    for i:= 0 to x.Count - 1 do begin
      tmp:= x[ i ];
      item:= ListViewMain.Items.Add;
      item.Caption:= IntToStr( TAccountDataExtend( tmp ).ID ); //Zeigt korrekte ID an
      item.Data:= Pointer( tmp );
    end;
  finally
    FreeAndNil( x ); //Ich nehme an die InterfaceList zerstört die Objekte nicht
  end;
end {LoadListView};

procedure GetAllAccounts( _o: TInterfaceList );
var
  tmp: IDataObject;//Oder IInterface?
begin
  for i:= 0 to 4 do begin
    tmp:= TAccountDataExtend.Create;
    TAccountDataExtend( tmp ).FID:= i;
    tmp._AddRef;
    _o.Add( tmp );
  end;
end {GetAllAccounts};


procedure TFormEditBase.ListViewMainClick(Sender: TObject);
var
  obj: IInterface;
  obj3: IDataObject;
begin
  Inherited;
  if ListViewMain.ItemIndex >= 0 then begin
    obj:= IInterface( Pointer( ListViewMain.Selected.Data ));
    if Succeeded( obj.QueryInterface( IDataObject, obj3 )) then begin
      obj3.Delete; //Funktion siehe unten
    end;
  end;
end;

//----------------- TAccountDataExtend
procedure TAccountDataExtend.Delete;
begin
  ShowMessage( IntToStr( FID )); //Gibt immer "0" aus
end {Delete};

Vielen Dank
RedOne

[himitsu]

tmp._AddRef; brauchst du bei einer InterfaceList nicht, da diese die Referenzzählung schon richtig behandelt.

also ab Delphi 2010 soll es ja nun so gehn (davor gibt es keinen offiziellen Weg, um aus einen Interface wieder ein Objekt zu machen)
> aber sowas würde ich hier nicht machen

Delphi-Quellcode:

var tmp: IInterface;

tmp:= TAccountDataExtend.Create;
(tmp as TAccountDataExtend).FID:= i;
_o.Add( tmp );

oder es erst noch als Objekt belassen und dann direkt übergeben (später umwandeln lassen)

Delphi-Quellcode:

var tmp: TAccountDataExtend;

tmp := TAccountDataExtend.Create;
tmp.FID:= i;
// aber tmp nicht zwischenzeitlich als Interface verwenden!!!
_o.Add( tmp );

oder es erst noch als Objekt belassen und später in ein Interface umwandeln

Delphi-Quellcode:

var otmp: TAccountDataExtend;
  tmp: IInterface;

otmp := TAccountDataExtend.Create;
otmp.FID:= i;
// aber tmp nicht zwischenzeitlich als Interface verwenden!!!
tmp := otemp;
// jetzt kann man das Interface verwenden
_o.Add( tmp );

oder besser doch so:

Delphi-Quellcode:

var tmp: IInterface;

tmp := TAccountDataExtend.Create(i);
_o.Add( tmp );

also entweder dein FID im Constructor mit übergeben
oder das FID auch im Interface verfügbar machen

Delphi-Quellcode:

IDataObject = interface( IInterface )
  ['{C94DCAC7-CA42-45D3-95D7-9BC321BA2E2A}']
  procedure Delete;
  property FID read ... write ...;  // bzw. nur eine SetFID-Prozedur
end;

var tmp: IInterface;

tmp := TAccountDataExtend.Create;
tmp.FID := i;  // tmp.SetFID(i);
_o.Add( tmp );

[RedOne]

Macht durchaus Sinn zuerst das Objekt zu erstellen und dann daraus ein Interface zu kreieren:

Delphi-Quellcode:

procedure GetAllAccounts( _o: TInterfaceList );
var
  tmp: TAccountDataExtend;
begin
  for i:= 0 to 4 do begin
    tmp:= TAccountDataExtend.Create;
    tmp.FID:= i;
    _o.Add( tmp );
    tmp._AddRef;
  end;
end {GetAllAccounts};

Sonst funktionierts nämlich nicht
Die Referenzzählung brauche ich meiner Meinung nach weil ich die InterfaceList zerstöre. Ansonsten bringt er eine Exception bei beenden des OnClick-Events.
Er gibt mir jetzt in der Deletefunktion meinen gewünschten Wert aus.
Dafür... im Grid nicht mehr Jetzt zeigt dieses immer "0" an.
Ich bekomme von der Funktion GetAllAccounts eine Interfacelist. Ich sollte diese doch gleich wie beim OnClick-Ereignis in ein TAccountDataExtend casten können?

Delphi-Quellcode:

var
  i: IDataObject;
  obj: IInterface;
  obj3: IDataObject;
  
begin
  obj:= IInterface( Pointer( ListViewMain.Selected.Data ));
  if Succeeded( obj.QueryInterface( IDataObject, obj3 )) then begin
    ShowMessage( TAccountDataExtend( obj3.XYZ ));
  end;
end;

Arbeite übrigens mit Delphi 2007

Vielen Dank

[RedOne]

Ich muss übrigens nicht zwingend diese Architektur verwenden. Wenn jemand eine schönere Lösung weiss, so bin ich gerne bereit alles umzubauen
Ich möchte einfach vermeiden dass in der Formklasse zusätzlich zum Grid eine Objektliste gepflegt werden muss und somit die Daten eigentlich doppelt vorhanden sind.
Im Anhang ein bescheidener Versuch diesen Teil der Software UML-mässig abzubilden. Musste mich zuerst im Enterprise Architect zurecht finden... deshalb etwas stümperhaft
Zu den beiden Formulare/Objekte Account und Action's gesellen sich noch einige mehr hinzu, deren Aufbau aber immer gleich ist.

Vielen Dank