Gleich vorweg - wer diesen Thread angeklickt hat, um mir zu sagen, mein Problem wäre mit Objektname.Variablenname := Wert gelöst, den muss ich enttäuschen.
Mein Programmziel ist folgendes:
Ich erstelle in Delphi ein Objekt, welches sich von einer Klasse ableitet, nennen wir das Objekt "Testobjekt" und die Klasse "Testklasse". Diese Klasse habe mehrere Eigenschaften, "TestEigenschaft1", "TestEigenschaft2", ...
Diese Eigenschaften sollen (sinnvollerweise) Werte erhalten, allerdings eben nicht mittels Testobjekt.TestEingeschaft1 := Wert.
Vielmehr möchte ich mit einem Parser eine Textdatei (oder Tabelle, spielt ja keine Rolle) auslesen, in der die Eigenschaft gefolgt von einem Spacer und dann dem Wert, den sie erhalten soll steht.

Nochmal schrittweise:
a) Objekt als Instanz der Klasse erstellen
b) Parser anwerfen
c) Parser findet eine Zeile nach dem Schema TestEigenschaft2[Spacer]Wert und tut (unterm Strich) das schon mehrmals angesprochene:
Testobjekt.Testeigenschaft2 := Wert.

Mir ist klar, dass ich das über eine Case-Konstruktion lösen könnte, die etwa wie folgt aussieht:


Dachte mir aber, dass das ja wohl einfacher gehen muss.
Bei meiner Suche stolperte ich nun über die von TObjekt abgeleitete Funktion FieldAddress. Leider Gottes ists mir bisher nicht gelungen, damit ein auch nur ein lauffähiges bisschen Stück Testcode zu bauen. Die Dokumentation der Sache in der Delphi-Hilfe ist irgendwie auch nich soo toll, da steht halt nur, dass auf Felder mithilfe von Properties zugegriffen werden sollte, und nicht über FieldAddress.

Hier noch eben die "Entwicklung" meines Testcodes:

1. Versuch


Resultat: Messagebox "Feld nicht gefunden".
Mein Lösungsansatz: Feld muss halt published sein (Steht in der Hilfe)



Rest ist gleich.
Resultat: Compilerfehler: Published-Feld 'Testwert1' ist weder vom Typ class noch interface.
(selbiges für die anderen Testwerte).
Mein Lösungsansatz: Dieser Thread

Danke im Vorraus für alle Hilfe(versuche)!

Mir ist in Delphi nur die Möglichkeit der Reflektion von published propertys bekannt wenn es um felder geht... Das was du da aber getan hast ist felder als Published zu deklarieren und keine propertys....



Das ist notwendig da FieldAdress wie du schon mitbekommen hast nur bei published propertys funktioniert

Nun taucht ein weiteres Problem auf es sind keine RunTimeTypeInformations(RTTI) andgelegt worden das kann man wiefolgt lösen :

1. deine Klasse muss von TPersistent abgeleitet sein

2. deine Klasse muss mit der entsprechenden Compiler Direktive compiliert werden (weis gerade nicht wie diese heist müsste aber in der Hilfe unter RTTI stehen)
Dies hat den Vorteil das du nicht von dem was TPersistant sonst noch einführt in deiner Klasse hast

Beide Möglichkeiten sorgen dafür das Delphi RTTI anlegt
Dann solltest du auch keinen nil pointer mehr zurück bekommen

3. Du basteslt was eigenes
Hiervon würde ich abraten es sein du hast vor etwas wie eine Scriptsprache oder andere Dinge zu tun bei dem das was Delphi von Haus aus kann nicht reicht

Wenn dir das alles nicht zusagt würde ich ein festes Dateiformat vorschlagen bei dem definiert ist welche Eigenschaft an welcher stelle ist...
jede zu laden / speichernden Klasse würde dann bei mir entsprechende Methoden (vll. auch ID; falls nicht klar ist welche Klassen sich an welcher stelle in der Datei befindet) erhalten

mfg FrenK

Nein, muss nicht. Es genügt, die Klasse mit der Direktive {$M+} zu kompilieren


siehe oben

Viele Grüße
Traude

Mhm, Traude, ich glaube, das meinte er sogar. War aber missverständlich.

Wenn man die von Delphi mitgelieferten Funktionen zum Schreiben und Lesen von Properties haben will, sollte man sich mal die TReader und TWriter-Klassen anschauen. Wenn ich mich recht erinnere, kümmern die sich um genau sowas.

Ansonsten empfehle ich dir, mal nach einer Referenz für die typinfo-Unit zu suchen. Dort sind die ganzen RTTI-Funktionen deklariert.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Okeh, entweder hab ich was falsch verstanden oder irgendwas läuft schief...



Resultat: Pointer ist nil.

Na so einfach ist es auch wieder nicht.

Wenn man ein Objekt mit der Compiler-Direktive {$M+} kompiliert, stellt der Kompiler Informationen über die Published Elemente (=Properties und Methoden) zur Verfügung.

Diese Daten können mit den Funktionen ausgelesen werden, die sich in der Unit TypInfo befinden. Vorsicht! Dort wird wird heftiger Gebrauch von Pointern gemacht.

Auszug aus der Hilfe meines Delphi7:



Du greifst oben auf ein Ding namens 'TestWert1' zu, aber das ist ein Property, kein Feld. Das Feld ist das 'FTestWert1', aber das ist wiederum nicht published deklariert, sondern protected.

Naja, wenn ich das Feld selbst aber versuche als published zu deklarieren (ist ja weiter oben schonmal probiert worden) krieg ich schon vom Compiler ne Fehlermeldung - {$M+} hin oder her...


Das da heftiger Gebrauch von Pointern gemacht wird ist mir bewusst, wird sich für meine Zwecke aber wohl nicht vermeiden lassen *sfz*

FieldAddress wird überwiegend von der VCL dazu benutzt um ein von TForm abgeleitetes Object zu erstellen. Die Unterkomponenten wie Button1 etc sind alle als Puplished Member implementiert. Dann kann man mit FieldAddress den Pointer erfragen und eine Instanz von TButton auf diesen Pointer zuweisen. ABER. Du hast keinerlei Typeninfos. Die Info um welche Klasse es sich handelt steckt in dem DFM (was als Resource eingebunden wird). Entsprechend weißt du nicht ob es sich bei dem Pointer um einen String, einen Integer oder ein Auto handelt. Die Wahrscheinlichkeit sich dabei was zu zerschießen ist also entsprechend groß.

TWriter und TReader sind eigentlich dazu da um Objekte zu streamen. Die benutzen zwar im Endeffekt auch die RTTI aber die machen vermutlich mehr als man bräuchte.

Wie das schon gesagt wurde solltest du alle Eigenschaften als Propertys implementieren und dann mittels RTTI drauf zugreifen. Wenn du das ein wenig abstract implementierst, dann brauchst du bloß ein paar Eigenschaftstypen implementieren. Dann könntest du auch automatisch Werte von Unterobjekte auslesen etc. Und du solltest darauf achten, dass du es nur ein mal implementieren müsstest. Also eine spezielle Klasse für bauen. Bei Bedarf könnte ich wohl auch ein bisschen Code locker machen. Ich habe so etwas in der Art schon für meine ollen Komponenten mal gemacht.

Ein Häppchen Code wär sicherlich hilfreich, da ich das Gebiet RTTI, Streaming etc. jetzt seit nicht ganz 24 Stunden erkunde und mit den Begriffen noch nicht wirklich was anfangen kann. Und die Delphihilfe hilft zumindest mir auf dem Gebiet auch praktisch überhaupt nicht. Entweder suche ich an den falschen Stellen oder diejenigen, die die Hilfe geschrieben haben, haben die Möglichkeit, dass jemand so etwas mal tatsächlich machen könnte geflissentlich ignoriert. Apropos ignoriert:
Darüber, dass ich den Typen der Variablen nicht kenne...sagen wir, ich hab dran gedacht, es aber verdrängt. Wenn ich vor einem Problem die Augen verschließe, dann betrifft es mich sicherlich auch nicht. Ziemlich naiv, ich weiß. Mal sehen, wie da ran zu gehen ist.

Mal deinen Post aus meiner sicht zusammengefasst:
a) FieldAddress ist irgendwie nicht der richtige Wert, eben, weil ich keine Informationen über Datentypen erhalte.
b) TReader und TWriter machen auch nicht das was ich will, sondern eher mehr.
c) Ich soll alle Felder als Properties implementieren. Das ist doch bei mir bisher so, oder nicht? (Btw.: Es sollte hierbei nicht bei Strings bleiben, auch wenn das Beispiel danach aussieht)
d) Der Zugriff soll dann mittels RTTI erfolgen. Und hier weiß ich schon nicht mehr, wie das dann codemäßig auszusehen hat. Von abstrakter Implementierung mal ganz abgesehen

Richtig. Deine letzte Klasse hat richtig Eigenschaften implementiert und diese rausgereicht.

Zum Thema Code. Sagen wir mal so. Ich tue mich ein wenig schwer dir ein kompletten Stück Code vor die Füße zu klatschen. Denn ob meine Struktur da so klasse ist lasse ich mal dahingestellt. Bzw wer weiß ob die so ohne weiteres auf deine Struktur übertragbar wäre. Du solltest dir aber eine Stelle überlegen an der du alle Fälle abfrühstücken kannst ohne, dass du den Code 20 mal schreiben musst. Prinzipiell würde auch folgendes ausreichen.
3 Methoden. 1 Methode der du ein Objekt und einen Namen übergibst. Als Ergebniss liefert sie ein PPropInfo und ein Objekt zurück (var parameter). In dem PPropInfo sind die Infos gespeichert damit die RTTI auf die Eigenschaft zugreifen kann. Und 2 Methode zum Lesen und Setzen einer Eigenschaft. Diese rufen dann Intern die Methode zum Finden einer Eigenschaft auf und setzen anhand des Typens den Wert.

In der Unit TypInfo ist die Methode GetPropInfo definiert. Mit dieser kannst du von einem Objekt eine Eigenschaft erfragen. Ist diese vorhanden bekommst du ein PPropInfo zurück. Wenn nicht, dann nil. Das PPropInfo hat ein Feld welches einen Typen angibt. "Prop^.PropType^^.Kind" ist ein bissel krank ja. Aber in Kind ist enthalten ob es sich um ein Unterobjekt, eine Enumeration, Float oder Ordinalwert handelt. Anhand von dem Typen musst du dann die entsprechende Methode aufrufen. Bei tkInteger zum Beispiel SetOrdProp.

Beispiel.

Das wars prinzipill schon. Du musst nur alle Typen einbauen die du unterstützen willst. Aber mit tkEnumeration, tkString, tkLString, tkWString, tkFloat und tkInteger kommst du schon recht weit. Zu mindest, wenn du noch Unterobjekte unterstützt. In meinem Code hatte ich anstelle des Aufrufen von GetPropInfo die Methode 1 aus der obrigen Struktur. Die hat dann so einen Namen wie "Button1.Caption" aufgelöst. Also die hat alle Identifier (Button1) abgetrennt und die Eigenschft erfragt. Wenn die vom Typ tkClass war bin ich hergegangen und habe mein aktuelles Object (nur methodeninterne Variable) durch Button1 ersetzt. Danach habe ich die Eigenschaft Caption des aktuellen Objektes (Button1) gesucht.

PS: Wenn es später performant sein soll, dann muss man versuchen die Arbeitschritte so gering wie möglich ausfallen zu lassen. Also wenn möglich muss man dann versuchen, dann man eine PropInfos zwischenspeichert und typenkonvertierungen reduzieren. Um nicht immer und immer wieder die Infos abklappern zu müssen. In einer Schleife dürfte der Aufwand da schon recht groß werden können. Also in einer Skriptsprache. Aber das nur als Anregung. Zu erst musst du es nach deinen Wünschen ans Laufen bekommen.

Neues von der Front...



Resultat: "Klappt!!!".
Großartig, danke so weit.
@performant:
Ich hatte eigentlich vor, alle Daten, die ich brauche beim Programmstart einmal auszulesen und in eine Art Basisinstanz zu schreiben, von der ich dann zur Laufzeit nur noch "Kopien" anfertigen muss, ohne nochmal etwas aus der Datei auslesen zu müssen.
Damit wären wir beim nächsten Thema
Hat jemand nen effizienten Weg auf Lager, um Kopien von Instanzen anzulegen?
Die erstbeste (und auch die, die ich bisher immer benutzt hab) Lösung ist ja, in einer Prozedur eine neue Instanz anzulegen und alle Werte nach dem Schema NeueInstanz.Wertx := BasisInstanz.Wertx zu übergeben. Ist das auch die einzige?

Nur zur Info: Du hast damit erfolgreich den Prototyp "neu erfunden", näheres hier:
http://de.wikipedia.org/wiki/Prototyp_(Entwurfsmuster)

Jep, das klingt schon ziemlich genau nach dem, was ich eigentlich realisieren wollte.
Mit einem gravierenden Unterschied:



Wobei ich noch gar nich genau weiß, obs wirklich ein Unterschied ist.
Meine Herangehensweise bisher wäre, hardcoded jeder Eigenschaft der Kopie den Wert der Eigenschaft des Prototypen zuzuweisen.
Da die Klassen um die es geht ca. 10 Properties und zusätzlich ein Array von 3-4 Instanzen einer weiteren Klasse haben, die übergeben werden müssten, wäre das ein (natürlich) schaffbarer, aber vermutlich recht hässlicher Batzen Code.
Nun ist in dem Wikipediaartikel ja von der Implementation einer Schnittstelle die Rede - existiert die Möglichkeit das durch ein Interface zu realisieren auch unter Delphi, und ist die Variante dann wirklich einfacher / eleganter / performanter? (Hab mich mit Interfaces noch nicht auseinandergesetzt...)

Ich wüsste nicht wie das mit Delphi interfaces elegant gelöst werden könnte mir fällt hierzu nur das ein :


da das der Fall ist kannst du auch alle Felder einer Klasse auf eine neue Übertragen wenn du weist wie groß alle Felder zusammen sind.
Ob das nun eine saubere Lösung ist mit einem Move() alles auf einmal zu übertragen würde ich mal in Frage stellen...
Dafür ermöglicht diese Variante das ganze einmalig in einer Basisklasse zu implementieren und die Funktionalität somit von den Feldern unabhängig zu implementieren.

Wichtig hierbei ist das damit keine pointer kopiert werden außer du willst das Kopie und Orginal an der Stellen mit dem gleichen Speicherbereich arbeiten!!!

wenn es weitere Fragen zum aufbau von Klassen in Delphi gibt würd ich mir das mal angucken
http://www.delphi3000.com/articles/article_3770.asp

Also Folgendes: Ich verstehe nichts von FieldAdress() und anderem Unsin Aber was ich aus deinem Beitrag rauslesen konnte, ist, dass du die Eigenschafften für ein Objekt aus einer Textdatei lesen möchtest?

Falls nicht, vergiss was ich schreibe^^ Sollte ich dich jedoch richtig verstanden haben, und solltest du keine professionellere Methode als meine finden, dann kann ich dir verraten wie ich sowas angehe, zB fürs Laden von Maps.

Meine Textdatei sieht folgendermaßen aus: Ich verwende '()' und '[]' um .. ich sag mal Items, und Subitems zu trennen (Spacer?). und so habe ich dann viele viele "([Objekt][Wert1][Wert2][Wert3])" in meiner Textdatei aus der ich die Geometrie für meine Levels lese. Ich lad den Text in ein Memo, hier gibts sicher bessere Möglichkeiten, und hab einige Funktionen und Prozdeduren zum auslesen geschrieben, zb "GetItem()", welchem ich die Nummer des Items, das ich ausgegeben haben will, mitgebe, und meine Begrenzungszeichen, also '(' und ')' oder eben eckige Klammern. mit GetItemCount lese ich wieviele Items es gibt (Anzahl der '('s), und jag das Ganze durch ne Schleife. Die ruft jeweils die richtige Procedure für die Konfiguration der Objekte auf (aka Objekt.Eigenschaft:=Wert ), man kanns aber auch in eine fette Prozedur quetschen.

Hab ich am Thema vorbeigequatscht?^^

Gruß, Robin.

_________________
thanks to the internet we have rule 34, wich states that if something exists, theres a pornographic version of it,