Autor |
Beitrag |
opfer.der.genauigkeit
      
Beiträge: 754
Erhaltene Danke: 1
|
Verfasst: Mo 17.01.05 15:40
Hi,
Ich hab folgendes Problem.
In einer Klasse A1 wurde eine property "test" im protected Bereich deklariert.
In der Klasse B1, die von A1 abgeleitet wurde, wird die Property "test" nicht mehr mitgezogen.
Erstelle ich jetzt eine Klasse B1 kann ich auf die Property "test" nicht zugreifen.
Gibt es eine Möglichkeit (außer in B1 die Property explizit nachzuziehen)
auf "test" zuzugreifen?
Es handelt sich um Klassen eines Drittanbieters, deshalb möchte ich da keine Änderungen vornehmen.
Ich stöber auch grad in der Hilfe und irgendwie verwirrt mich das ganze.
Steh grad eh n bissl auf'm Schlauch.. aber ziemlich mit allem
Thx
_________________ Stellen Sie sich bitte Zirkusmusik vor.
|
|
UGrohne
      

Beiträge: 5502
Erhaltene Danke: 220
Windows 8 , Server 2012
D7 Pro, VS.NET 2012 (C#)
|
Verfasst: Mo 17.01.05 15:42
Wenn die Eigenschaft im protected-Bereich deklariert wurde, dann müsstest Du auch darauf zugreifen können. Zeig mal ein bisschen Code, am besten auch nen (am besten etwas verfremdeten) Ausschnitt aus dem Komponenten-Code.
|
|
Lossy eX
      
Beiträge: 1048
Erhaltene Danke: 4
|
Verfasst: Mo 17.01.05 16:05
Also wenn sie im Protected Teil steht kann man bei einer Instanze nicht darauf zugreifen. Das Einfachste was mir an der Stelle einfallen würde wäre, dass du die Property in B1 in den Publicteil hebst. Oder du leitest eine Klasse von B1 ab und hebst die Property dort in den Public Teil.
Delphi-Quelltext 1: 2: 3: 4:
| TBlub = class(B1) public propryt Name; end; |
Wenn du dann ein TBlub erstellst dann sollte es gehen. Evtl geht es auch wenn du TBlub(B1) machst und du die nicht als TBlub erstellt hast. Da bin ich mir aber nicht so ganz sicher.
_________________ Nur die Menschheit ist arrogant genug, um zu glauben sie sei die einzige intelligente Lebensform im All. Wo nicht mal das nachhaltig bewiesen wurde.
|
|
opfer.der.genauigkeit 
      
Beiträge: 754
Erhaltene Danke: 1
|
Verfasst: Mo 17.01.05 16:09
Ok,
N bißchen Code und die Problemstellung nochmal konkretisiert:
Ursprungsklasse
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
| TMyCustomClass = class(TAnotherClass) private FTest: Longint; protected property Test: Longint read FTest write FTest; public constructor Create(bla: Tbla); override; destructor Destroy; override; procedure Assign(Source: TPersistent); override; end; |
Abgeleitete Klasse
Delphi-Quelltext 1: 2: 3: 4: 5: 6:
| TMyDerivedClass = class(TMyCustomClass) private FDescription: TCaption published property Description: TCaption read FDescription write FDescription; end; |
Mein Code:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7:
| procedure Test; var MyItem: TMyDerivedClass; begin MyItem := TMyDerivedClass.Create; MyItem.Test := 0; end; |
Ich kann natürlich über eine Instanz der Klasse TMyDerivedClass nicht auf
die Property von TMyCustomClass zugreifen.
Zitat: |
Ein protected-Element ist innerhalb des Moduls mit der Klassendeklaration und in allen abgeleiteten Klassen (unabhängig davon, in welchem Modul sie deklariert sind) sichtbar. Mit anderen Worten: auf ein protected-Element können alle Methoden einer Klasse zugreifen, die von der Klasse mit der Elementdeklaration abgeleitet ist. Mit diesem Sichtbarkeitsattribut werden also Elemente deklariert, die nur in den Implementierungen abgeleiteter Klassen verwendet werden sollen.
|
Ich möchte jetzt aber nicht extra die Klasse umschreiben.
Gibt es eine "saubere" Möglichkeit mit der ich trotzdem auf die Eigenschaft zugreifen kann? Codehacks sind auch erwünscht
Thx.
_________________ Stellen Sie sich bitte Zirkusmusik vor.
|
|
UGrohne
      

Beiträge: 5502
Erhaltene Danke: 220
Windows 8 , Server 2012
D7 Pro, VS.NET 2012 (C#)
|
Verfasst: Mo 17.01.05 16:12
Folgender Kommentar aus der Delphi-Hilfe:
Delphi-Hilfe hat folgendes geschrieben: | Ein protected-Element ist innerhalb des Moduls mit der Klassendeklaration und in allen abgeleiteten Klassen (unabhängig davon, in welchem Modul sie deklariert sind) sichtbar. Auf ein protected-Element können alle Methoden einer Klasse zugreifen, die von der Klasse mit der Elementdeklaration abgeleitet ist. Mit diesem Sichtbarkeitsattribut werden also Elemente deklariert, die nur in den Implementierungen abgeleiteter Klassen verwendet werden sollen. Ein public-Element unterliegt keinerlei Zugriffsbeschränkungen. |
Damit dürfte das eigentlich funktionieren ...
//EDIT: Ich habs gerade mal probiert, ich kann sowohl auf protected, als auch auf priavte deklarierte Variablen zugreifen 
Zuletzt bearbeitet von UGrohne am Mo 17.01.05 16:19, insgesamt 1-mal bearbeitet
|
|
opfer.der.genauigkeit 
      
Beiträge: 754
Erhaltene Danke: 1
|
Verfasst: Mo 17.01.05 16:13
Hm ja, ist mir klar.
Ich wollt bloß nix an der Klasse ändern (bzw. darf ich nicht).
Trotzdem danke.
_________________ Stellen Sie sich bitte Zirkusmusik vor.
|
|
UGrohne
      

Beiträge: 5502
Erhaltene Danke: 220
Windows 8 , Server 2012
D7 Pro, VS.NET 2012 (C#)
|
Verfasst: Mo 17.01.05 16:22
Ach, jetzt versteht ich Dein Problem, Du willst von außen darauf zugreifen ....
Dazu musst Du in Deiner abgeleiteten Klasse ein property schreiben. Darin kannst Du mal versuchen direkt auf das property Test der Elternklasse zuzugreifen. Sollte das nicht gehen, machst Du es einfach über eine weitere Prozedur für das property.
|
|
opfer.der.genauigkeit 
      
Beiträge: 754
Erhaltene Danke: 1
|
Verfasst: Mo 17.01.05 16:23
Du kannst drauf zugreifen?
Ich nicht. *grübel*
Du kannst innerhalb der Klasse drauf zugreifen oder?
Nicht aber über die Instanz oder doch. *kopf kratz*
Dann weiß ich nicht warum Delphi mir das verbietet.
Edit: Ja, jetzt verstehen wir uns.  Wie gesagt, ich darf die Klasse weder ableiten noch editieren. Es handelt sich dabei um eine visuelle Klasse und ich darf (wg. Arbeitgeber) keine Änderungen vornehmen.
_________________ Stellen Sie sich bitte Zirkusmusik vor.
|
|
UGrohne
      

Beiträge: 5502
Erhaltene Danke: 220
Windows 8 , Server 2012
D7 Pro, VS.NET 2012 (C#)
|
Verfasst: Mo 17.01.05 16:35
Daher musst du es mit einem property in der abgeleiteten Klasse machen. Hier nochmal ein Beispielcode, um das zu verdeutlichen:
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41:
| TMyCustomClass = class(TAnotherClass) private FTest: Longint; protected property Test: Longint read FTest write FTest; public constructor Create(bla: Tbla); override; destructor Destroy; override; procedure Assign(Source: TPersistent); override; end;
TMyDerivedClass = class(TMyCustomClass) private FDescription: TCaption published property Test: Longint read Test write Test; property Description: TCaption read FDescription write FDescription; end;
TMyDerivedClass2 = class(TMyCustomClass) private FDescription: TCaption procedure WriteTest(value:longint); function ReadTest:Longint; published property Test: Longint read ReadTest write WriteTest; property Description: TCaption read FDescription write FDescription; end;
implementation
procedure TMyDerivedClass.WriteTest; begin Test:=value; end;
function TMyDerivedClass.ReadTest:LongInt; begin result:=Test; end; |
Wenn ich keinen groben Denkfehler gemacht habe, dann müsste mindestens das zweite funktionieren.
|
|
Lossy eX
      
Beiträge: 1048
Erhaltene Danke: 4
|
Verfasst: Mo 17.01.05 16:45
UGrohne: Ich denke mal, dass er bei der Zweiten Methoden auf die Property Test der eigenen Klasse zugreifen wird. Das dürfte in einer Rekursion enden! Und das erste dürfte in Compilerfehlern enden wenn ich richtig denke. Ist aber nur geraten. Zu mindest das zweite.
Wenn du in der Abgelittenen Klasse einfach nur noch mal die Property definierst. Also OHNE read und write dann geht es. Das wird in der VCL tausendfach verwendet. Also bei den Componenten TCusomListbox definiert alle Property im protected und TListBox liefert nur noch einmal alle Propertys in den Published Teil.
Delphi-Quelltext 1: 2: 3:
| Published Property Test; end; |
_________________ Nur die Menschheit ist arrogant genug, um zu glauben sie sei die einzige intelligente Lebensform im All. Wo nicht mal das nachhaltig bewiesen wurde.
|
|
UGrohne
      

Beiträge: 5502
Erhaltene Danke: 220
Windows 8 , Server 2012
D7 Pro, VS.NET 2012 (C#)
|
Verfasst: Mo 17.01.05 16:48
Lossy eX hat folgendes geschrieben: | UGrohne: Ich denke mal, dass er bei der Zweiten Methoden auf die Property Test der eigenen Klasse zugreifen wird. Das dürfte in einer Rekursion enden! Und das erste dürfte in Compilerfehlern enden wenn ich richtig denke. Ist aber nur geraten. Zu mindest das zweite. |
Stimmt, darauf hatte ich nicht geachtet ... irgendwie hatte ichs im Blut, dass es nicht funktionieren würde.
Und die andere Möglichkeit kannte ich noch nicht, man lernt nie aus 
|
|
MitschL
      
Beiträge: 211
Win 98 SE, Win 2000
D5 Pers, D6 Pers und D7 Pro
|
Verfasst: Mo 17.01.05 16:56
Moin,
des Pudels Kern ist doch sein Wolle und zwar immer. Das was der gute UGrohne macht, ist ein Überschreiben der Property, was nur geht, wenn man den gleichen Namen verwendet. Dann geht auch sowas:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
| type TAncestor = class private _test: Integer; protected Property Test: Integer read _test write test; end;
type TDerive = class( TAncestor ) published Property Test; end; |
Dann kannst Du üebr eine Instanz darauf zugreifen.
gegrüßt!
[edit] Ich bin zu spät und poste es trotzdem 
_________________ "Bloßes Ignorieren ist noch keine Toleranz." (Theodor Fontane)
|
|
opfer.der.genauigkeit 
      
Beiträge: 754
Erhaltene Danke: 1
|
Verfasst: Di 18.01.05 10:28
Ok,
als ich meinte, dass ich die Klasse garnicht ableiten dürfte, hab ich das schon ernst gemeint. Die anderen Sachen sind mir sogar fast klar.
Trotzdem danke. 
_________________ Stellen Sie sich bitte Zirkusmusik vor.
|
|
MitschL
      
Beiträge: 211
Win 98 SE, Win 2000
D5 Pers, D6 Pers und D7 Pro
|
Verfasst: Di 18.01.05 10:44
Moin,
Wie jetzt? Darfst Du nun ableiten, oder nicht? Laut deinem Eingangsposting und den Code-Snippsels darfst du, was die Lösungen zeigen. Damit würdest du ja auch nicht die Basisklasse verändern.
Wenn du nicht ableiten darfst, kommst du nicht an protected/private-Daten.
gegrüßt!
MitschL
_________________ "Bloßes Ignorieren ist noch keine Toleranz." (Theodor Fontane)
|
|
opfer.der.genauigkeit 
      
Beiträge: 754
Erhaltene Danke: 1
|
Verfasst: Di 18.01.05 11:46
Zitat: |
Es handelt sich um Klassen eines Drittanbieters, deshalb möchte ich da keine Änderungen vornehmen.
|
Zitat: |
Ich möchte jetzt aber nicht extra die Klasse umschreiben.
|
Zitat: |
Ich wollt bloß nix an der Klasse ändern (bzw. darf ich nicht).
|
Habs n paar mal erwähnt, aber hätte wohl gleich sagen sollen, daß ich es nicht darf. 
_________________ Stellen Sie sich bitte Zirkusmusik vor.
|
|
MitschL
      
Beiträge: 211
Win 98 SE, Win 2000
D5 Pers, D6 Pers und D7 Pro
|
Verfasst: Di 18.01.05 12:18
Wenn Du von einer Klasse ableitest, dann änderst du nichts an dieser Klasse. Du brauchst lediglich eine Möglichkeit, diese einzubinden - also eine Unit, oder vergleichbares, welches du in deine uses-Klausel setzen kannst. Dann erstelltst Du eine abgelittene Klasse und hast von hier aus Zugriff auf die Members dieser Fremdklasse.
gegrüßt!
MitschL
_________________ "Bloßes Ignorieren ist noch keine Toleranz." (Theodor Fontane)
|
|
opfer.der.genauigkeit 
      
Beiträge: 754
Erhaltene Danke: 1
|
Verfasst: Di 18.01.05 12:37
Argh..
das ist mir klar.
Ich darf NICHT ABLEITEN.. egal in welcher Form und Weise.
Das höchste der Gefühle ist es die Komponente auf mein Formular klatschen zu dürfen. 
_________________ Stellen Sie sich bitte Zirkusmusik vor.
|
|
Lossy eX
      
Beiträge: 1048
Erhaltene Danke: 4
|
Verfasst: Di 18.01.05 12:42
@Opfer: Hätteste ja auch gleich sagen können, dass du das nicht darfst.
Ham wir wohl irgendwie alle überlesen.
Was auch noch gehen würde wäre folgendes.
Delphi-Quelltext 1: 2: 3: 4:
| THackTest = class(TMyCustomClass) public property Test; end; |
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7:
| procedure Test; var MyItem: TMyDerivedClass; begin MyItem := TMyDerivedClass.Create; THackTest(MyItem).Test := 0; end; |
In Wirklichkeit ist das gar keine Instanze von THackTest. Delphi erlaubt aber dennoch den Zugriff auf eine Property. Und der Aufruf wird 100%tig umgesetzt, da die Property ja existiert. Nur halt eben nicht mit der normalen Sichtbarkeit.
Das wäre aber auch wieder eine Ableitung. Obwohl du die ja dann auch nicht benutzen würdest. Aber ich schätze mal das wäre auch nicht erlaubt. Ohne Ableitung wirst du das dann wohl vergessen können!!! Evtl. musst du dir mal die Klassen anschauen wie die auf den Wert kommen und das dann selber machen. Also über freigelegt Eigenschaften und Methoden etc. Wenn das auch nicht geht würde ich fast sagen, dass du etwas anderes benutzt! Software mit so einer engstirnigen Lizenz gehört aus den Programierstuben verbannt...
_________________ Nur die Menschheit ist arrogant genug, um zu glauben sie sei die einzige intelligente Lebensform im All. Wo nicht mal das nachhaltig bewiesen wurde.
|
|
MitschL
      
Beiträge: 211
Win 98 SE, Win 2000
D5 Pers, D6 Pers und D7 Pro
|
Verfasst: Di 18.01.05 12:49
So langsam glaube ich zu verstehen, worauf du hinauswillst. Die Komponente darf, wenn sie denn eingesetzt würde, nur selbst eingesetzt werden. Es dürfen auch keine Erben genutzt werden, weil diese die von dir erwähnte Veränderung ausmachen. Nun ich sah Veränderung in einem anderen Kontext.
Wenn Du die Komponente benutzen darfst, diese Eigenschaft aber protected ist, dann kommst du nicht ran, was ja der Sinn der Datenkapselung ist. Vielleicht gibt eine weitere Eigenschaft der Komponente aufschluß über die von dir gesuchte Eigenschaft.
... nich' ableiten dürfen... Ts! Wer verbietet sowas!
gegrüßt!
_________________ "Bloßes Ignorieren ist noch keine Toleranz." (Theodor Fontane)
|
|
opfer.der.genauigkeit 
      
Beiträge: 754
Erhaltene Danke: 1
|
Verfasst: Di 18.01.05 14:05
MitschL hat folgendes geschrieben: |
... nich' ableiten dürfen... Ts! Wer verbietet sowas!
|
Eine Firmenrichtlinie.
No Comment...
_________________ Stellen Sie sich bitte Zirkusmusik vor.
|
|