AW: Frage zum "is"-Operator
Hallo nochmal.
Ich habe noch ein wenig debugged. Folgendes ist herausgekommen: Nicht "ActiveControl" produziert das Problem. Hier der stark vereinfachte Code:
Code:
Der Pointer wird durch das Neufüllen der UI/Grid (wahrscheinlich im Grid) geändert. Hier die Ergebnisse von "GetClassInheritancePathFrom"
var
ActiveCtrl : TWinControl; begin ActiveCtrl := Self.ActiveControl; ShowMessage(GetClassInheritancePathFrom(ActiveCtrl)); // 1 // UI wird gefüllt oder geleert und dann neu gefüllt ShowMessage(GetClassInheritancePathFrom(ActiveCtrl)); // 2 end; // 1: TObject->TPersistent->TComponent->TControl->TWinControl->TCustomEdit->TcxCustomInnerTextEdit // 2: TObject->TPersistent->TComponent->TcxComponent->TcxControlChildComponent->TcxCustomGridView->TcxCustomGridTableView->TcxGridTableView Hinweis: ActiveControl ist zum zeitpunkt "// 2" = NIL. Das Problem ist, dass "TcxGridTableView" nicht von "TWinControl" erbt. |
AW: Frage zum "is"-Operator
Zitat:
Beispiel: TObject -> TMyObject -> TMySubObject
Code:
Vielleicht habe ich mich unglücklich ausgedrückt. Ich möchte wissen ob das Objekt, auf das ein Pointer zeigt, von einem Typ ist oder von diesen erbt. In zum Beispiel Java gibt es instanceof. Das Gegenstück dazu brauche ich in Delphi.
var
obj1 : TMyObject; obj2 : TMySubObject; begin obj1 := (TMyObject.Create); obj2 := (TMySubObject.Create); if (obj2.ClassName = 'TMyObject') then; // ist immer False end; |
AW: Frage zum "is"-Operator
|
AW: Frage zum "is"-Operator
TcxGridTableView ist kein Control, das zugehörige Control is TcxGrid.
|
AW: Frage zum "is"-Operator
Zitat:
|
AW: Frage zum "is"-Operator
Zitat:
Du füllst in einen Eimer Wein, dann schaust du eine Weile nicht hin und ein Anderer säuft den Wein aus und wieder ein Anderer füllt Wasser rein, weil der Eimer ja leer war (ist also Platz gewesen). Was findest du jetzt in dem Eimer? Aha. Du hast doch schon selber festgestellt, dass du dir nur eine Referenz (Pointer) auf das Objekt hast und damit kann man das Objekt nicht festhalten, wenn es freigegeben wird. Ein anderes Beispiel ist eine Visitenkarte von Peter Lustig. Der wohnt nicht in oder auf der Visitenkarte, sondern das ist nur eine Referenz auf seinen Wohnort. Zieht der Peter jetzt dort aus und dann ein Anderer wieder ein, dadurch wird dieser Andere nicht automatisch zu Peter Lustig. |
AW: Frage zum "is"-Operator
Zitat:
Zum zweiten Beispiel: Wenn ich eine Referenz auf einen Wohnort von Peter Lustig habe, dann zieht da nach Peter Lustig nicht einfach ein Kaugummi ein, sondern eine andere Person (gleicher Typ). Ich weiß aber was du damit sagen willst. Dieses Laufzeitverhalten ist dennoch unglücklich und extrem gefährlich. So kann man sich nie darauf verlassen, dass das worauf man zugreift auch das ist was man ursprünglich annahm (insbesondere wenn man mit externen Bibliotheken arbeitet). Leider ist das in vielen Bereichen von Delphi so (siehe Reference Counting von Interfaces, das wohl nur noch Delphi so betreibt). Naja, da kann man wohl nichts machen. Vielen Dank für eure Hilfe. :) |
AW: Frage zum "is"-Operator
Zitat:
oder das Haus wird abgerissen und man fällt in ein Loch (Speicher komplett freigegeben, oder irgendwas Anderes ist dort ... z.B. ein Stück eines Strings oder ein Integer) oder Petra Miesepeter zieht ein (Frau und nicht lustig, also nicht ger gleiche Typ ... original war dort ein Mann) |
AW: Frage zum "is"-Operator
@QStorm
Wenn man weiß, was man macht, bzw. was man zulässt, dann ist das kein Problem. Du hast hier mit keinem Wort verraten, was zwischen dem 1. und 2. Zugriff passiert.
Delphi-Quellcode:
ist z.B. wie den Blick vom Eimer wenden und dann kann dort alles passieren (z.B. die Instanz zur Referenz wird aus dem Speicher geworfen).
Application.ProcessMessages
Und das ist nur eine der vielen 1000 Möglichkeiten. Wenn der Bauer nicht schwimmen kann, dann ist natürlich die Badehose Schuld |
AW: Frage zum "is"-Operator
Zitat:
Delphi-Quellcode:
und macht genau das was du beschreibst. :? Vielleicht hast du ganz falsche Erwartungen davon, was da passiert?
is
Ich hab mal dein Beispiel von Anfang (ein bisschen abgeändert) getestet:
Delphi-Quellcode:
Ausgabe:
program tistest;
{$mode objfpc} uses Classes; var stringList : TStringList; obj : TObject; control : TInterfacedObject; begin stringList := (TStringList.Create); obj := TObject(stringList); control := TInterfacedObject(obj); // ich hatte keine Lust Controls einzubinden... Writeln(control.ClassType.ClassName); Writeln(control is TInterfacedObject); // dürfte unter Delphi glaub ich nicht funktionieren, da das kein Writeln(Boolean) kennt :P end.
Code:
Gruß,
TStringList
FALSE Sven |
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:01 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz