Basisklassenroutine kann nicht auf vererbte Variablen zugreifen?

[hboy]

Hallo,

entschuldigt die blöde Frage, aber mir scheint hier wirklich etwas grundlegendes entgangen zu sein:
Ausgehend von einer Basisklasse wird an eine weitere Klasse vererbt.

Delphi-Quellcode:

type TBasisKlasse = class
public
  Variable: Boolean;
  function TestVariable: Boolean; virtual;
end;

type TAbgeleiteteKlasse = class(TBasisKlasse)
public
  procedure ModifiziereVariable;
end;

implementation

function TBasisKlasse.TestVariable: Boolean;
begin
  result := Variable;
end;

procedure TAbgeleiteteKlasse.ModifiziereVariable;
begin
  Variable := true;
end;

Nun erzeuge ich eine neue Instanz, lasse die Variable ändern...

Delphi-Quellcode:

var allgemeineVariable : TBasisKlasse;
begin
  allgemeineVariable := TAbgeleiteteKlasse.Create;
  (allgemeineVariable  as TAbgeleiteteKlasse).ModifiziereVariable;
  if allgemeineVariable.TestVariable then [...]

und sie ist immer false. Es scheint fast, als ob die Variablen einfach doppelt vorhanden wären und für die Methoden der abgeleiteten Klasse verdeckt. Wenn ich die Testmethode als abstrakt definiere und in der abgeleiteten Klasse ausimplementiere, tut alles wie gewohnt.

Klärt mich da mal bitte kurz auf! Danke schonmal :-)

[Stevie]

Der Code ist korrekt und das von dir geschilderte Verhalten sollte nicht passieren - bist du ganz sicher, dass du das genau so in deinem Programm machst und es nicht an etwas anderem liegt?

Hinweis: Ich hoffe die Variable ist in deinem richtigen Code zumindest protected und du kapselst den Zugriff nach außen über eine Property :) Hat aber keinen Einfluss auf das angesprochene Fehlverhalten.

[hboy]

Danke Stevie. Die Variable ist im richtigen Code als private deklariert und wird nur als interner Zustand genutzt, der sich auf das event handling auswirkt, ich habe das nur sinngemäß der Darstellung wegen umgeschrieben, nachdem ich geprüft hatte, dass es sich bei public-Variablen ebenso verhält.

Um das Drumherum aufzuzeigen:

Delphi-Quellcode:

Type TUserInteractionHandler = class(TObject)
private 
    ConnectionIsValid : Boolean;
public
    OnDisconnect      : TNotifyEvent;
    property Connected: Boolean read IsConnected;

    procedure Connect( ... ); virtual;
    procedure Disconnect;

    procedure VectorObjectsChanged(Sender: TObject); 
end;


Type TCreatePointHandler= class(TUserInteractionHandler)
    procedure Connect( ... ); override;
end;


procedure TCreatePointHandler.Connect( ... ); 
begin
   ...
   ConnectionIsValid  := True;
   ...
end;

procedure TUserInteractionHandler .VectorObjectsChanged(Sender: TObject);
begin
  if ConnectionIsValid then
  begin
     ...
  end;
end;

VectorObjectsChanged wird vom Besitzer der Instanz ausgelöst, wobei die Instanz als TUserInteractionHandler angesprochen wird. In der Behandlung der Fallprüfung soll dann das Event OnDisconnect ausgelöst werden, jedoch ist auch diese Variable nil.

edit : Sorry, da ist etwas beim zusammenschneiden durcheinandergekommen.
edit 2 : ich habe es noch einmal zurückgebaut und beobachte tatsächlich das beschriebene Verhalten. Dabei scheint es unerheblich zu sein, ob die Methode in der Basisklasse nun als virtual, dynamic oder one Direktive klassifiziert ist. Der Debugger springt ab einem breakpoint davor auch in die Routine der Basisklasse, in der die Variable als "False" evaluiert wird. Andere Variablen, die im obigen Auszug nicht aufgelistet sind, werden ebenfalls als 0 oder nil evaluiert.
edit 3 : Delphiversion ist 10.0

[Stevie]

Dass OnDisconnect nil ist, ist klar. Es handelt sich hier um ein Event (Methodenpointer) und da generell alles in einem Objekt erstmal genullt wird, ist dieser Pointer nil. Du musst dem Event einen Eventhandler zuweisen.

[hboy]

Zitat:

Zitat von Stevie (Beitrag 1104898)

Dass OnDisconnect nil ist, ist klar. Es handelt sich hier um ein Event (Methodenpointer) und da generell alles in einem Objekt erstmal genullt wird, ist dieser Pointer nil. Du musst dem Event einen Eventhandler zuweisen.

Das Zuweisen geschieht bereits beim Erzeugen der Instanz. Ungeachtet der Zuweisung, die auch beim Aufruf von Connect() erfolgen könnte, sehen andere Methode das Event als korrekt zugewiesen, nur beim Sprung in die Methode der Basisklasse wird sie als nil aufgelöst.

[Stevie]

Zitat:

Zitat von hboy (Beitrag 1104902)

nur beim Sprung in die Methode der Basisklasse wird sie als nil aufgelöst.

Und der geschieht ganz normal über inherited?

[hboy]

Ich schreibe mal ein Beispiel dazu, mein erster Versuch ist an der Delphi IDE gescheitert ...

[Aphton]

Wartet mal, bleiben wir beim Ausgangsproblem, beim Abstrakten.

Denn dieses angeführte Beispiel funktioniert bei mir unter Turbo Delphi Explorer.
Ich habs so gemacht:

Delphi-Quellcode:

var
  B: TBasisKlasse;

begin
  B := TAbgeleiteteKlasse.Create;
  try
    B.Variable := False;
    if B.TestVariable then Writeln('Testvariable #1');
//    TAbgeleiteteKlasse(B).ModifiziereVariable;
    (B as TAbgeleiteteKlasse).ModifiziereVariable;
    if B.TestVariable then Writeln('Testvariable #2');
  finally
    B.Free;
    Readln;
  end;
end.

Das zweite Writeln klappt. Also klappt das Ändern der Variable per ModifiziereVariable!

[hboy]

ich habe eben das hier implementiert:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils;

type TBaseClass = class
private
  B: Boolean;
public
  function ReturnVal: Boolean; virtual;
  procedure SetToTrue; virtual; abstract;
end;

type TDerivedClass = class(TBaseClass)
public
  procedure SetToTrue; override;
end;


function TBaseClass.ReturnVal: Boolean;
begin
  result := B;
end;

procedure TDerivedClass.SetToTrue;
begin
  B := True;
end;


var
  inst: TBaseClass;
begin
  inst := TDerivedClass.Create;
  (inst as TDerivedClass).SetToTrue;

  writeln(BoolToStr(inst.ReturnVal,true));
  readln;
end.

und es tut auch... ich suche mal weiter!

[Aphton]

Also besteht das Problem immernoch, wenn du die abstrakte Definition von SetToTru in TBaseClass entfernst?
Ist mal interessant... Also was für ne Delphi Version benutzt du? (Weil ich hier das Problem nicht habe!)

Edit: Omg deine Signatur ist köstlich!

[implementation]

Ähem ...
Wie wäre es, wenn du die Variable statt auf private mal auf protected stellen würdest?
Private-Zeugs ist in Nachkommen nicht mehr zugänglich.
In dem Screenshot hattest du die Variable dort neu deklariert.
Das heißt: Sie existiert dann auf einmal 2x!
DAS ist das Problem.

[Aphton]

Omg du könntest sogar recht haben..

[hboy]

Ich habe jetzt auf die Schnelle einen Objektzeiger und eine Boolean-Variable bei besagter Basisklassenmethode und bei einer Methode einer abgeleiteten Klasse ausgeben lassen und das beruhigt mich nun irgendwie nicht.

022A5294 False (Basisklasse)
022A524C True (abgeleitete Klasse)

Es ist etwas schwer, ein Beispielschnipselchen zu schreiben, das realitätsgetreu ist, da die Methode nach dem Auslösen eines Clickereignisses mittelbar über einen Ereignisknoten ausgelöst wird - aber auch dieser hat nur eine Liste von TNotifyEvent-Verweisen, die er abarbeitet. Vielleicht spielt es auch eine Rolle, wem die Instanz gehört. (jetzt werde ich vollends paranoid)

[hboy]

Zitat:

Zitat von implementation (Beitrag 1104917)

Ähem ...
Wie wäre es, wenn du die Variable statt auf private mal auf protected stellen würdest?
Private-Zeugs ist in Nachkommen nicht mehr zugänglich.
In dem Screenshot hattest du die Variable dort neu deklariert.
Das heißt: Sie existiert dann auf einmal 2x!
DAS ist das Problem.

der Screenshot ist auch nur just for fun, weil mir die IDE an der Stelle gecrasht ist und dass die Variable dort drinsteht, ist ein Copy&Paste-Fehler (Was bitte ist " auf (???).Personality kann nicht zugegriffen werden." oder so ähnlich für ein IDE-Fehler?)

[Stevie]

Zitat:

Zitat von implementation (Beitrag 1104917)

Ähem ...
Wie wäre es, wenn du die Variable statt auf private mal auf protected stellen würdest?
Private-Zeugs ist in Nachkommen nicht mehr zugänglich.

Innerhalb derselben Unit schon.

[hboy]

Ok, nehmen wir vielleicht einen Schritt Abstand, von außen sehen beide Implementierungen gleich aus,

Delphi-Quellcode:

Type TUserInteractionHandler = class(TObject)
private
    obj: TObject;
    ConnectionIsValid : Boolean;
    IsConnected       : Boolean;
public
    OnDisconnect      : TNotifyEvent;
    procedure Disconnect; 
    procedure VectorObjectsChanged(Sender: TObject); virtual; abstract;
end;

Type TCreatePointHandler = class(TUserInteractionHandler)
public
  procedure VectorObjectsChanged(Sender: TObject); {override;} // edit: das override ist unerheblich.
end;

implementation

procedure TUserInteractionHandler.Disconnect;
begin
  ConnectionIsValid := False;
  IsConnected := False;
  if assigned(OnDisconnect) then OnDisconnect(Self);
end;

procedure TCreatePointHandler.VectorObjectsChanged(Sender: TObject);
begin
  if assigned(obj) and ConnectionIsValid then
     Self.Disconnect;
end;

und zum Zweiten

Delphi-Quellcode:

Type TUserInteractionHandler = class(TObject)
private
    obj: TObject;
    ConnectionIsValid : Boolean;
    IsConnected       : Boolean;
public
    OnDisconnect      : TNotifyEvent;
    procedure Disconnect; 
    procedure VectorObjectsChanged(Sender: TObject); virtual; 
end;

Type TCreatePointHandler = class(TUserInteractionHandler)
end;

implementation

procedure TUserInteractionHandler.Disconnect;
begin
  ConnectionIsValid := False;
  IsConnected := False;
  if assigned(OnDisconnect) then OnDisconnect(Self);
end;

procedure TUserInteractionHandler.VectorObjectsChanged(Sender: TObject);
begin
  if assigned(obj) and ConnectionIsValid then
     Self.Disconnect;
end;

erstere tut das, was man erwartet, letztere nicht. Warum?


ps.: bei anderen Methoden, die etwas direkter aufgerufen werden, löst der Aufruf einen EAbstractError aus, wenn man die Override-Direktive weglässt, bei der angeführten Methode scheint der Aufruf jedoch keinen Fehler zu produzieren, ob man override hinschreibt oder nicht. Es werden keine Warnungen ausgegeben. Übrigens nutze ich den Turbo Delphi Explorer (build 10.0.2228.42451) unter Windows 7 (64 bit)

[Stevie]

Wenn du das override weglässt, verdeckst du die gleichnamige Methode aus der Elternklasse. Das heißt, wenn du eine Variable vom Typ TUserInteractionHandler hast und darauf VectorObjectsChanged aufrufst, gibts nen EAbstractError, weil der Aufruf nicht an die VectorObjectsChanged von TCreatePointHandler geht (Stichwort: Polymorphismus)
Müsste aber Warnings oder Hints beim Kompilieren geben.

P.S. Was erwartet man denn? Was rufst du denn auf?

[hboy]

Ich rufe VectorObjectsChanged auf, um der Handlerinstanz mitzuteilen, dass sich etwas an der Datenstruktur geändert hat, etwa wenn Objekte gelöscht oder hinzugefügt wurden, während der Handler verbunden ist.
Dann wird geprüft, ob nach dem letzten Kenntnisstand noch alles funktioniert hat (ConnectionIsValid)

Wenn das Objekt gelöscht wurde, auf das aktuell zugegriffen wird (dann kann die hinterlegte UID des Objekts nicht mehr aufgelöst werden), wird eben die Existenz des Objekts über die UID in VectorObjectsChanged geprüft und bei dem Befund, dass das Objekt weg ist, wird der Handler abgetrennt. Über OnDisconnect werden dann die zugehörigen Anzeigeelemente zurückgesetzt, sprich der zugehörige tbCheck-ToolButton wird wieder herausgenommen.

Ich kann noch immer nicht erklären, was hier vor sich geht und nein, es gibt keine Warnung, dass eine Methode durch das fehlende Override verdeckt wurde, was auch sehr unlogisch ist.

Delphi-Quellcode:

procedure TCreatePointHandler.VectorObjectsChanged(Sender: TObject);
begin
  if assigned(Manager) and ConnectionIsValid then
  begin
    if VectorObjID > -1 then
     if (Manager.PointGroupList.IndexByID(VectorObjID ) = INDEX_NOT_RESOLVED) then // We've lost him, Sir.
       Self.Disconnect;
  end;
end;

[himitsu]

@implementation: Auf Private-Felder kann man außerhalb der Klasse, aber innerhalb der selben Unit noch zugreifen.

Aus diesem Grunde wurde auch irgendwann ( D2006? ) mal das

Delphi-Quellcode:

strict private

und

Delphi-Quellcode:

strict protected

eingeführt, welches dann auch innerhalb der selben Unit diese Rechte "strikt" durchsetzt.

[Delphianer]

Hallo,

wird das Disconnect nicht aufgerufen oder steht die Variable ConnectionIsValid falsch?
Hast Du auch wirklich nur ein Objekt oder erzeugst Du fälschlicherweise noch ein zweites?

Lutz

[hboy]

Zitat:

Zitat von Delphianer (Beitrag 1105003)

Hallo,

wird das Disconnect nicht aufgerufen oder steht die Variable ConnectionIsValid falsch?
Hast Du auch wirklich nur ein Objekt oder erzeugst Du fälschlicherweise noch ein zweites?

Lutz

gut möglich, dass ich gestern abend beim debuggen unterschiedliche Instanzen beim breakpoint in der Basisklassenmoethode gesehen habe, das würde die unterschiedlichen Adressen erklären - jedoch kann das, wie ich es überblicke, auch nicht erklären, wieso es nicht unerheblich ist, ob die Methode in der Basisklasse abstrakt oder explizit angelegt ist.

[Delphianer]

Hallo,

kannst du mir mal die ganze Unit + nicht funktionierenden Aufruf als PN schicken?

Lutz