Scheinbar Verständnissproblem bezüglich Interfaces...

[Kedariodakon]

Ok, ich hab mal was mit Interfaces versucht, um in die Thematik ein wenig einzusteigen...
Dies anhand von einem kleinen Beispiel Programm... (Projekt ist zusätzlich angehangen)

Delphi-Quellcode:

Unit FInterfaceTest;

Interface

Uses  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
      Dialogs, StdCtrls;

Type
  IPNameRead = Interface( IInterface )
    ['{801B392E-D9A7-4705-93DD-4822F032E33C}']
    Function  GetName:  String;
  End;
  
  IPNameWrite = Interface( IPNameRead ) //  Wer schreiben kann, kann auch lesen ;)
    ['{7B1C4BAC-213C-4DD3-8EAB-A5A37DEEB123}']
    Procedure SetName( Const  Value:  String );
  End;

  IPValues = Interface( IInterface )
    ['{0062AA2E-96AA-4C5D-85CD-83C946083887}']
    Function  GetValue:  Variant;
    Procedure SetValue( Const  Value:  Variant );
  End;
  

  TIObjBase = Class( TInterfacedObject, IPNameWrite )
  Private                    
    { Private-Deklaration }
    FName:  String;
  Protected
    { Protected-Deklaration }
    Function  GetName:  String;               Virtual;
    Procedure SetName( Const Value: String ); Virtual;
    Property  Name: String  Read GetName  Write SetName;
  Public                     
    { Public-Deklaration }
  End;

  TIObj = Class( TIObjBase, IPValues )
  Private                    
    { Private-Deklaration }
    FValue: Variant;
  Protected
    { Protected-Deklaration }
    Function  GetValue: Variant;
    Procedure SetValue( Const Value: Variant );
  Public                     
    { Public-Deklaration }
    Property  Name;
    Property  Value:  Variant Read GetValue Write SetValue;
  End;                                    

{ Hier beginnt die Form... (So Übersichtshalber ^^ ) }
  
  TfrmInterfaceTest = Class( TForm )
    txtName: TEdit;
    txtValue: TEdit;
    lblName: TLabel;
    lblValue: TLabel;
    cmdRead: TButton;
    cmdWrite: TButton;
    rbTIObjBase: TRadioButton;
    rbTIObj: TRadioButton;
    procedure rbObjTypClick(Sender: TObject);
    procedure cmdReadClick(Sender: TObject);
    procedure cmdWriteClick(Sender: TObject);
  Private
    { Private-Deklarationen }
    FMyObj: TObject;
  Protected
    { Protected-Deklaration }
    Procedure CreateRbObj;   
    Procedure GetMyObjValues;
    Procedure SetMyObjValues;
  Public
    { Public-Deklarationen }
    Constructor Create( AOwner: TComponent);  Override;
    Destructor  Destroy;  Override;
    Property  MyObj:  TObject Read FMyObj Write FMyObj;
  End;

Var frmInterfaceTest: TfrmInterfaceTest;

implementation

{$R *.dfm}
{ TIObjBase }

Function TIObjBase.GetName: String;
Begin
  Result  := FName;
End;

Procedure TIObjBase.SetName( Const Value: String );
Begin
  FName := Value;
End;      

{ TIObj }

Function TIObj.GetValue: Variant;
Begin
  Result  := FValue;
End;

Procedure TIObj.SetValue( Const Value: Variant );
Begin
  FValue  := Value;
End;

{ Hier beginnt die Form... (So Übersichtshalber ^^ ) }
{ TForm1 }

Constructor TfrmInterfaceTest.Create( AOwner: TComponent );
Begin
  Inherited;
  CreateRbObj;  //  Das kleine wird erzeugt... =p
End;

Destructor TfrmInterfaceTest.Destroy;
Begin
  If Assigned( MyObj )  Then FreeAndNil( FMyObj ); //  Ist ja public, da kann viel passieren... ;)
  Inherited;
End;

Procedure TfrmInterfaceTest.CreateRbObj;
Begin
  If Assigned( MyObj )  Then FreeAndNil( FMyObj ); //  Ist ja public, da kann viel passieren... ;)  
  If          rbTIObjBase.Checked Then Begin
    MyObj := TIObjBase.Create;
    ( MyObj As TIObjBase ).Name   := 'TIObjBase'; //  geht da protected und in der selben Unit... ^^    
  End Else If rbTIObj.Checked     Then Begin
    MyObj := TIObj.Create;
    ( MyObj As TIObjBase ).Name   := 'TIObj';     //  geht da protected und in der selben Unit... ^^    
    ( MyObj As TIObj     ).Value  := 'Ein String Wert...';
  End;  //  Bei allem anderen ist MyObj ja NIL, was nicht passieren sollte... ;)
  GetMyObjValues;
End;

Procedure TfrmInterfaceTest.rbObjTypClick( Sender: TObject );
Begin
  { Radiobutton wurde geändert bzw. angeklickt... ==> Neues Objekt }
  CreateRbObj;
End;

Procedure TfrmInterfaceTest.cmdReadClick( Sender: TObject );
Begin
  GetMyObjValues;
End;

Procedure TfrmInterfaceTest.cmdWriteClick( Sender: TObject );
Begin
  SetMyObjValues;
End;

Procedure TfrmInterfaceTest.GetMyObjValues;
Var IPV:  IPValues; 
    IPNR: IPNameRead; 
    IPNW: IPNameWrite;
Begin

  txtValue.Enabled  := Assigned( MyObj ) And Supports( MyObj, IPValues, IPV );  //  MyObjWert: (0, 'TIObjBase')
  If txtValue.Enabled Then Begin  //  MyObjWert: (24, '') //  WARUM ????????????
    txtValue.Text := IPV.GetValue;
    IPV           := Nil;
  End Else Begin
    txtValue.Text := '';
  End;

  txtName.Enabled  := Assigned( MyObj ) And Supports( MyObj, IPNameRead, IPNR );  //  EXCEPTION...
  If txtName.Enabled Then Begin
    txtName.Text := IPNW.GetName;
    IPNR         := Nil;
  End Else Begin
    txtName.Text := '';
  End;
End;

Procedure TfrmInterfaceTest.SetMyObjValues;
Begin
  //  ... Soweit bin ich noch nichtmal gekommen... =(
End;

end.

So, das knallt mir gleich mal beim erstellen, siehe Kommentare....

So, wenn ich den Block:

Delphi-Quellcode:

  txtValue.Enabled  := Assigned( MyObj ) And Supports( MyObj, IPValues, IPV );  //  MyObjWert: (0, 'TIObjBase')
  If txtValue.Enabled Then Begin  //  MyObjWert: (24, '') //  WARUM ????????????
    txtValue.Text := IPV.GetValue;
    IPV           := Nil;
  End Else Begin
    txtValue.Text := '';
  End;

auskommentiere komm ich aber nicht in den nächsten If-Then Block, weil er scheinbar das Interface IPNameRead (obwohl es ja durch IPNameWrite vererbt werden sollte oder?) nicht erkennt... Tausche ich das aus, mit IPNameWrite kommt er in den Block und liest das auch aus, aber wenn ich erneut auslese kommt beim aufruf von Supports(...) wieder eine Exception...

Ich hoffe es steigt wer durch das Gewusel von mir und kann mir verdeutlichen, warum das nicht so will, wie ich mir das denke... :drunken:

Bye Christian

[shmia]

Du hast ein Objekt mit mehreren Interfaces. Wenn du das Objekt erzeugst und in einer
Objektvariablen speicherst, ist der Referenzzähler=0.
Wenn du dir einen Interfacepointer besorgst, wird der Referenzzähler (Property RefCount) auf 1 erhöht.
Sobald der Interfacepointer auf nil gesetzt oder ausserhalb des Scope gerät, wird der Referenzzähler auf 0 erniedrigt und automatisch der Destructor aufgerufen.
Deine Objektvariable zeigt jetzt auf ein ungültiges Objekt.

Abhilfe:
a.) nicht Objektvariablen und Interfacepointer parallel benützen
oder
b.) Zusätzlichen Interfacepointer benützen, um das Objekt am Leben zu halten:

Delphi-Quellcode:

var
   FMyObj: TObject;     // Objektvariable (auch ein Zeiger)
   FIMyObj : IUnknown;  // Interfacepointer

...
   FMyObj:= TObject.Create;
   FIMyObj := FMyObj as IUnknown;
// ab jetzt darf man mit FMyObj (oder FIMyObj) arbeiten
...
...
// nun kommt der Zeitpunkt des Todes
   FIMyObj := nil;
   FMyObj := nil;
// FMyObj.Free ist aber nicht erlaubt !!!

[DGL-luke]

c.) _AddRef aufrufen :twisted:

[Kedariodakon]

Zitat:

Zitat von shmia

Du hast ein Objekt mit mehreren Interfaces. Wenn du das Objekt erzeugst und in einer
Objektvariablen speicherst, ist der Referenzzähler=0.

Gut, das habe ich schon nachvollzogen... =)

Zitat:

Zitat von shmia

Wenn du dir einen Interfacepointer besorgst, wird der Referenzzähler (Property RefCount) auf 1 erhöht.

Das passiert bei mir auch schon beim Versuch, scheinbar zählt der schon... ^^

Zitat:

Zitat von shmia

Sobald der Interfacepointer auf nil gesetzt oder ausserhalb des Scope gerät, wird der Referenzzähler auf 0 erniedrigt und automatisch der Destructor aufgerufen.
Deine Objektvariable zeigt jetzt auf ein ungültiges Objekt.

Ok, wie hoch ist die/das Scope?

Zitat:

Zitat von shmia

Abhilfe:
a.) nicht Objektvariablen und Interfacepointer parallel benützen
oder

Ok, wie würde man das am obrigen Bespiel am dümsten machen?

Vielleicht mal meinen Einstieg, was wollte ich mit den Interfaces erreichen?
Ganz knapp, ich bekomm ein TObjekt und kann einfach nachschauen ob ich einen Namen auslesen kann, einen Namen zuweisen kann, dem Objekt ein Value zuweisen oder ganz schlimm, dies auch alles oder teilweise...

Nun ich dachte dies mithilfe von vielen Interfaces durchführen zu können... :drunken:
Is das der Weg, in die richtige Richtung?
Hab in die Richtung noch nie gearbeitet und bin dahingehend noch Jungfrau... :duck:

Zitat:

Zitat von shmia

b.) Zusätzlichen Interfacepointer benützen, um das Objekt am Leben zu halten:

Delphi-Quellcode:

var
   FMyObj: TObject;     // Objektvariable (auch ein Zeiger)
   FIMyObj : IUnknown;  // Interfacepointer

...
   FMyObj:= TObject.Create;
   FIMyObj := FMyObj as IUnknown;
// ab jetzt darf man mit FMyObj (oder FIMyObj) arbeiten
...
...
// nun kommt der Zeitpunkt des Todes
   FIMyObj := nil;
   FMyObj := nil;
// FMyObj.Free ist aber nicht erlaubt !!!

:wiejetzt:
Ausserhalb des Objekts?

Ich danke schonmal für die Antwort =)

Edit:

Zitat:

Zitat von DGL-luke

c.) _AddRef aufrufen :twisted:

Wo?... =)


Bye Christian...

[Kedariodakon]

So nun war ich mal ganz böse und habe im Constructor "_AddRef" aufgerufen, damit nicht immer alles zerstört wird...
Das ist keine Lösung, aber es hilft mir schon mal ein wenig tiefer in die Materie einzublicken...

Dabei hab ich nach dem erstellen von "TIObjBase" (MyObj: TObject = TIObjBase.Create;) folgendes getestet:

Delphi-Quellcode:

  If  Supports( MyObj, IInterface ) Then Begin
    Beep; { Hier gehts durch, ist Ok }
  End;
  
  If  Supports( MyObj, IPNameRead ) Then Begin
    Beep;  { Hier gehts nicht durch, ist nicht Ok  WARUM ??? }
  End;

  If  Supports( MyObj, IPNameWrite ) Then Begin
    Beep;  { Hier gehts durch, ist Ok }
  End;

  If  Supports( MyObj, IPValues ) Then Begin
    Beep;  { Hier gehts nicht durch, ist Ok }
  End;

Dabei ist mir aufgefallen, dass scheinbar "IPNameRead" unterschlagen wird...
Da aber "IPNameWrite" von "IPNameRead" abgeleitet ist, versteh ich das eigendlich nicht so, müste er da nicht auch durch den entsprechenden Block?

Bye Christian

[xaromz]

Hallo,

Zitat:

Zitat von Kedariodakon

So nun war ich mal ganz böse und habe im Constructor "_AddRef" aufgerufen, damit nicht immer alles zerstört wird...
Das ist keine Lösung...

Da gebe ich Dir Recht.

Zitat:

Zitat von Kedariodakon

Dabei ist mir aufgefallen, dass scheinbar "IPNameRead" unterschlagen wird...
Da aber "IPNameWrite" von "IPNameRead" abgeleitet ist, versteh ich das eigendlich nicht so, müste er da nicht auch durch den entsprechenden Block?

Wenn Du Dein TIObjBase deklarierst, musst Du beide interfaces angeben:

Delphi-Quellcode:

TIObjBase = Class( TInterfacedObject, IPNameRead, IPNameWrite )

Außerdem möchte ich Dir meine Einführung in Interfaces ans Herz legen, wenn Du Dich tiefer damit beschäftigen willst. Das wollte ich zwar schon lange überarbeitet, aber brauchbar ist es auch so.

Gruß
xaromz

[Kedariodakon]

Nunja, im Grunde hab ich die Funktionsweise schon verstanden...

Nun, das Problem ist aber, dass ich eigendlich mit normalen Objekten arbeite und dies auch weiterhin intern so handhabe möchte...

Nun kommt aber hinzu, dass ich diese Objekte nach außen zugänglich machen möchte und dies natürlich Objektunabhängig, sondern Parameter abhängig...

Das Problem dabei ist, dass da die Objekte mit Interfaces vermischt werden, was zwangsweise immer irgendwo zu Problemen führt...

Was ich also brächte wäre eine Interface Schnittstelle zum Objekt ohne das Interface im Objekt selbst zu integrieren.... (schwer zu erklären)... Nur hab ich keine Ahnung wie man sowas realisieren könnte...

Bye Christian

[shmia]

Meine Variante b) von Oben ist eigentlich eine einfache Möglichkeit Objektvariablen und Interfaces zu mischen.
Wenn das Objekt z.B. in einem Formular eingebettet ist, dann reicht es:

Delphi-Quellcode:

private 
   FMyObj: TObject;     // Objektvariable 
   FIMyObj : IUnknown;  // Interfacepointer (darf auch ein anderes Interface sein z.B. IPValues)

procedure TForm1.FormCreate;
begin
   FMyObj:= TObject.Create; 
   FIMyObj := FMyObj as IUnknown;
end;

Du brauchst dich ab jetzt selbst nicht mehr um die Freigabe kümmern. (Create and Forget)
Wenn das Formular zerstört wird, wird auch FIMyObj entfernt und alles ist in Butter.
Das Gleiche gilt ganz allgemein für Objekte, die in einem anderen Objekt eingebettet sind.

Du kannst auch den Sourcecode von TComponent anschauen und besonders auf VCLComObject achten.
TComponent ist so eine Art Zwitterwesen, dass einmal als normales Objekt arbeitet aber auch der Referenzzählung von COM unterliegen kann.
Der "Trick" von oben ist aber deutlich einfacher.

[Kedariodakon]

Ok, also ich hab mir ein neues Basis-Object gebastelt, welches an TComponent angeleht wurde...

Nun, das funktioniert erstmal sehr gut, nur hab ich ein Problemchen, mit offenen Interfaces...

Ich hab das Object mit einem Referenzzähler erweitert nunja und es knallt natürlich wenn noch Interfaces offen sind...
( Muss man ja mal testen... ;))

Hab ich eine Chance die Interfaces zu schließen, bevor ich mein Objekt zerstöre? Ev. eine Interface Liste, für offene Interfaces, um diese freizugeben?

Gibts Ideen?

Bye Christian