![]() |
Re: Verschachtelte Objekte
@ HalloDu:
Vielen Dank! Ja, das mit dem zugreifen auf übergeordnete Variablen ist hier wirklich das Problem. @ DGL-luke: Habe ich jetzt gesehen :oops: |
Re: Verschachtelte Objekte
Liste der Anhänge anzeigen (Anzahl: 1)
Zum Vergleich hab ich das Beispiel noch mal eben mit Verebung geschrieben um zu demostrieren wie das funktioniert.
Hoffe es hilft dir bei deinem Problem. :) |
Re: Verschachtelte Objekte
Die Vorwärtsdeklaration führte bei mir nur zu abstürzen bei Zugriffen auf die Objekte, aber ich habe das ganze jetzt mit Properties gelöst. So kann ich wenigstens auf Variablen übergeordneter Obejekte zugreifen.
Delphi-Quellcode:
Allerdings bin ich damit meinen eigentlichen Ziel, einen Ersatz für TWebbrowser Anweisungen zu schreiben nicht wirklich näher gekommen, da ich nicht weiß ob man Objekten so wie Prozeduren Argumente übergeben kann.
type
Tjeep = class protected geschwindigkeit : integer; public procedure fahren; end; type Tpkw = class protected temp : integer; procedure writespeed (speed : integer); public jeep : Tjeep; property geschwindigkeit : integer read temp write writespeed; end; implementation procedure Tpkw.writespeed (speed : integer); begin temp := speed; jeep.geschwindigkeit := temp; end; procedure Tjeep.fahren; begin showmessage ('Jeep fährt '+inttostr(geschwindigkeit)); end; *Twebbrowser besteht allerdings trotz der "WebBrowser1.OleObject.document.frames.item(0).doc ument.links.item(0).click;" Struktur auch nicht aus verschachtelten Objekten, sondern ist ein Variant (wie auch immer dieser dann konkret aufgebaut ist...) |
Re: Verschachtelte Objekte
Delphi-Quellcode:
ist ebenafalls klassische OOP und könnte inetwa so aussehen:
WebBrowser1.OleObject.document.frames.item(0).document.links.item(0).click;
Delphi-Quellcode:
Um Zugriff von TWebBrowser auf den 1. Frame und dessen 1. Link zu erhalten um dessen OnClick aufzurufen muß man also
type
TWebBrowser = class property OleObject: TOleObject; end; TOleObject = class property document: TDocument; property links: TLinksList; end; TDocument = class property frames: TFrameList; end; TFrameList = class property Item[Index]: TItem; end; TItem = class property document: TDocument; end; TLinkList = class property Item[Index]: TLink; end; TLink = class property OnClick: TNotifyEvent; end; // Hierarchie als Objekte ist dann TWebBrowser TOleObject TDocument TFrame(0) TDocument TLink(0) TLink(1) TFrame(1) TDocument TLink(0) TLink(0) TLink(1) WebBrowser.OleObject.Document.Frames.Items[0].Document.Links.Item[0].OnClick; aufrufen. Also EXAKT das was du möchtest und auch nur mit stinknormelem OOP realisiert ! Fazit: Nenne mir bitte ein anders praktisches Beispiel das dein Problem realer erklärt. Gruß Hagen |
Re: Verschachtelte Objekte
Nein, negaH, das ist nicht das, was er will, siehe meinen beitrag #7.
|
Re: Verschachtelte Objekte
Ich weis das es nicht das ist, aber das was er möchte ist das was er als Beispiel mit TWebBrowser angeführt hat. Ergo: er fragt aus meiner Sicht nach einem Konzept, nach Möglichkeit auch umsetzbar. Und das was ich oben aufgezeigt habe ist das was heutztage als OOP Konzept am verbreitesten ist.
Es gibt einen Weg exakt das machen zu können was er sich vorstellt, zumindestens sähe es im Source so aus. Man arbeitet mit Interfaces -> COM Objecten abgeleitet von IDispatch und deren späten Bindung. Das ist Vergleichbar mit den Ole Objekten beim Zugriff auf ein Word-Dokument. Allerdings: die Implementierung im Source sieht wieder exakt so aus wie normales OOP nur eben dieses mal zusätzlich noch IINteerfaces basieren auf IDispatch. In der endgültigen Anwendung wird man nun sein TWebBroweser Objekt als Variant speichern. Zb. so
Delphi-Quellcode:
Da unsere Objekt Instance im Variant Obj ein IDispatch ist und wir als Variante darauf zugreifen KANN der Compiler NICHT wissen welche Eigenschaften, Methoden etc.pp unser Objekt in Obj real implementiert. Also greift die späte Bindung und der Compiler legt im compilierten Code einen String als Konstante ab die etwa so aussieht:
var
Obj: Variant; begin Obj := CreateMyObject; Obj.Starte.Dies.Und.Mache.Das.An.Position(0).OnCLick; end; "Starte.Dies.Und.Mache.Das.An.Position(0).OnCL ick" Das bedeutet das du nun in deiner Objekt Implementation durchaus immer neuere Funktionen/Methoden und Hierarchien anlegen kannst und der Endanwender deiner Lib das erst zur Laufzeit quasi als interpretierbaren String aufruft, späte Bindung halt. Nur, konzeptionell gesehen wird dann denoch der eigene Code gewohnt als OOP programmiert. Gruß Hagen |
Re: Verschachtelte Objekte
Er will aber nicht
Erst.A.dann.B.und.da.gehts.noch.weiter.runter sondern er will Adam.Kain.Moses.Jesus.Luther, wenn man mal davon ausgeht, dass sich die vererben.... Für einen Fall wie in TTreeNodes oder im Document Object Model kann ich das auch nachvollziehen. Aber nicht für Klassenmodellierung. Ich finde erstens das Ziel grässlich und zweitens jede mögliche Umsetzung mindestens genauso grässlich. Und auch dein Zitat:
|
Re: Verschachtelte Objekte
Zitat:
Wenn wir also zb. wie bei der VCL auf ein TEdit zugreifen wollen dann müssten wir also immer so arbeiten if TObject.TPersistent.TComponent.TCustomControl.TWin Control.TCustomEdit.TEdit.?????.Cpation = 'Test' then Also ehrlich gesagt verstehe ich den Sinn nicht dabei. Wir dereferenzieren damit ja immer nur eine Klassenhierarchie und keine lebendigen Objecte. Deshalb auch die Fragezeichen ???? in dieser Kette, denn normalerweise wollen wir ja eine Instance einer Klasse von TEdit die auf einem TForm liegt ansprechen. Desweiteren kann es keine multiplen TEdit auf einem Form geben, da es ja nur eine eindeutige Klasse TEdit geben kann. Ich glaube ich muß den Thread ein Drittes mal komplett lesen damit ich die Frage verstehe ? Bin nur ich so blöde ? Gruß Hagen |
Re: Verschachtelte Objekte
:lol:
Diese Antwort hatte ich jetzt nicht erwartet, aber genau das will der Thread-Ersteller (nb! nicht ich): Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:19 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz