Auf Klassenvariablen indiziert zugreifen?

[Joerginger]

Hallo Delpi-Mitbrüder (und Schwestern),

ich habe eine von TRemotable abgeleitete Klasse Article

Code:

Article = class(TRemotable)  //DURCH WSDL-IMPORT SO BENAMST...
  private
    FOXID: TXSString;
    FOXSHOPID: TXSString;
    FOXPARENTID: TXSString;
    FOXACTIVE: TXSBoolean;
    //geht natürlich elendslang weiter... alle Felder aus OXID Artikelstamm

Wie unschwer zu erkennen ist hat das Teil generell keine Variablen im Einsatz, sondern nur die Delphi-nilable-Variante, wiederum Klassen, im Einsatz.

Wenn ich jetzt einen Artikel in den Shop hochschiessen möchte mach ich:

Code:

  //ARRAY UM 1 SATZ VERGRÖSSERN
  setLength(aArt,iDX+1);
  aArt[iDX]:=Article.create;  //ARTIKEL BASTELN
  aArt[iDX].OXID:=TXSstring.Create; //ERSTES FELD BASTELN
  aArt[iDX].OXID.XSToNative('05848170643ab0deb9914566391c0c63'); //WERT ZUWEISEN
  aArt[iDX].OXTitle:=TXSstring.Create; ...
  aArt[iDX].OXTitle.XSToNative('Tescht mit ÄÖÜäöüß uns allen Spielis by EJ...');
  aArt[iDX].OXActive:=TXSBoolean.Create;
  aArt[iDX].OXActive.asBoolean:=True;
  aArt[iDX].OXPRICE:=TXSDecimal.Create;
  aArt[iDX].OXPRICE.XSToNative(SoapFloatToStr(6.99));
  aArt[iDX].OXVAT:=TXSDecimal.Create;
  aArt[iDX].OXVAT.XSToNative(SoapFloatToStr(-1));

... iss natürlich möglich und funktioniert, ich würd mir aber gerne eine Procedure basteln (ungefähr so lautend)

Code:

//NUR ALS BEISPIEL! VARIABLE = ICH WEISS NICHT WAS ICH VERWENDEN SOLL...
procedure OXWriteField(Feldname:variable;iDX:integer;sStr:ansiString);
//iDX = INDEX IM ARRAY
//sStr = WERT ZU SCHREIBEN

die ich dann z.B. mit

Code:

OXWriteField('OXTITLE',1,'Des Artikels neue Bezeichnung');

aufrufen kann und die dann das jeweilige Feld instanziert und mit TX richtig befüllt. Im Endeffekt würd ich es dann noch 3 x overloaden, damit ich boolean, decimal, integer und string richtig abhandeln kann.
aArt ist Globales Array, von daher auch in der procedure im Zugriff...

Nur: ich kriegs nicht gebacken...

wenn ich aArt[iDX].sFN ansprechen will meckert D2010 berechtigterweise, dass es sFN nicht kennt. Mit (sFN) bzw. [sFN] tuts genausowenig. Gibts doch sicher einen ganz einfachen Weg dafür, der mit grad nicht einfällt...

Bin zur Zeit ohne :idea:

GLG,

Erwin J.

[Aurelius]

Hallo Joerginger,

das sollte mit Introspection funktionieren. Grob gesagt kannst du hiermit zur Laufzeit Informationen über den Aufbau von Objekten/Klassen abfragen (Variablen, Funktionen etc.). Mangels Delphi kann ich das nicht selbst testen, allerdings spuckt Google dazu einige Links aus.

http://www.buehling.org/?book=blog&d...-introspection
https://en.wikipedia.org/wiki/Type_i...#Object_Pascal

Ich hoffe das hilft dir weiter.

[Lemmy]

Tach,

wenn Du die 2010er Version gekauft hast, dann hast Du gewisse Chancen, dass du zusätzlich das Buch "Delphi 2010 Handbook" von Marco Cantu dazu erhalten hast - herunterzuladen bei Embarcadero bei deinen Downloads bzw in CodeCentral:
http://cc.embarcadero.com/Item/27613

Hier erklärt Marco u.a. die neue RTTI mit der Du auf die Properties zugreifen kannst. Du kannst auch die "alte" RTTI verwenden, dazu einfach mal die Unit TypeInfo einbinden und anschauen.

Grüße

[himitsu]

Auf Published-Property kann man auch schon mit der alten RTTI drauf zugreifen.

Man kann aber notfalls auch die Variablen als Array erstellen und dann über indizierte Property drauf zugreifen, hab aber auch den Vorteil alles über's Array ansprechen zu können.


Wenn du auf private Felder über die neue RTTI zugreifen willst, dann vergiß nciht, daß du dann etwas größere EXEn hast, da diese RTTI-Infos auch mit einkompilieren mußt. (deaktivieren der zugehörenden RTTI-Infos sollte man dann vermeiden, aber da hierdurch die Anwendungen nun einfacher gehackt werden können, ist sowieso egal)

[Joerginger]

Mal vorab Danke für die Wortspenden!

Introspection... gut zu wissen für weitere Projekte, aber einerseits weiss ich ja den Namen, den ich übergeben will, ich wills ja auch nicht durchiterieren, sondern einfach nur ein (bekanntes) Feld per Namen ansprechen (oder per Pointer oder what so ever). Und mit diesem Feld eben Sachen anstellen, wie z.B. ein := TXCreate oder einen Wert zuweisen. Und andererseits geht das so wie ich das verstehe nur bei public... Die Felder sind allerdings allesamt Private.

Wenn ichs direkt (siehe Beispiel) zuweise funktionierts ja ad hoc. Wenn ich aber diese Zuweisung aus Gründen der Lesbarkeit in eine eigene PROC packen will kann ich nicht auf das Feld zugreifen, weil ich eben nicht weiss WIE?

Was schon geklappt hat war, den ganzen String (aArt[iDX].OXID) als TXSString zu übergeben, in der Proc eine Variable TXSString zu basteln, die zu createn und mit dem Wert zu bestücken und hernach per := der übergebenen TXSString zuzuweisen. Halte ich aber für Grenzwertig und net sauber...

@Lemmy: Du setzt bei mir leider zuviel Wissen voraus :oops::shock: Ich bin noch nicht so weit das alles zu kapieren...

@Himitsu: danke, aber WIE greife ich zu darauf... Das ist das was mir fehlt :roll:

greetz, Joerginger (A.K.A. Erwin)

[Joerginger]

Vielleicht hab ich auch zu kompliziert gefragt, ist ja noch zeitig des Morgens für mich...

Wenn ich eine procedure TUWAS(sStr:string); habe, kann ich mit TUWAS('juhu'); drauf zugreifen und habe 'juhu' im Zugriff. Ich kann sStr:=''; sagen, ich kann sStr:=sStr+'di'; schreiben und erhalte 'Juhudi' etc.

Nun würde ich gern ein bekanntes Feld (z.B. 'OXID') einer bekannten Klasseninstanz (aArt[index]) einer Prozedur übergeben um ebendort in dieser Prozedur auf selbiges Feld zuzugreifen, so wie ich es auch im aufrufenden Code kann... Brauche ich dazu wirklich die RTTI?

Code:

    //Hier funktioniert das...
    aArt[iDX].OXID:=Article.create;  //gar kein Problem

Ich will nur diesen Aufruf Create und die Wertzuweisung in eine extra Prozedur auslagern, damit ich nicht so eine große Aufrufende Prozedur habe... Und dazu müsste ich der aufgerufenen Prozedur doch sagen können, welches Feld ich beackern will???

greetz, Erwin J.

[Lemmy]

Zitat:

Zitat von Joerginger (Beitrag 1232705)

@Lemmy: Du setzt bei mir leider zuviel Wissen voraus :oops::shock: Ich bin noch nicht so weit das alles zu kapieren...

ich entschuldige mcih jetzt gleich mal vorab: Ich setze zu viel Wissen voraus um ein BUCH zu lesen? ;-) OK ist in englisch. aber selbst die "alte" RTTI kann das mit 2-3 Methodenaufrufen in 5 Zeilen Code.

http://delphitutorials.de/node/20

ein Tutorial, das sich damit beschäftigt - hat zwar ein etwas anderes Ziel, aber die Vorgehensweise sollte damit eigentlich klar werden:

Properties als published deklarieren und mit dem Compilerschalter M+ arbeiten oder die Klassen von TPersistend ableiten und nicht von TObject
dann "einfach" auslesen:

Delphi-Quellcode:

  iCount:=GetPropList(oAdresse,PropertyList);
  for idxIndex := 0 to iCount - 1 do begin
  PropInfo:=PropertyList^[iIndex];
  if PropInfo<>nil then begin
    aValue:=GetPropValue(oAdresse,PropInfo^.Name);
    aLabelText:=aLabelText+' '+aValue;
  end;

dito für das schreiben.

[DeddyH]

Sicher geht das, Du musst halt die Werte als Parameter übergeben, das ganze SetLength()-, Create()- und Zuweisungs-Gedöns geschieht dann eben in dieser Prozedur.

[Joerginger]

@DeddyH: ja, genau das ist es, ich will Parameter übergeben... Aber WIE?

Das habe ich, das funktioniert. Es wird in der Klasse Artikel (die wegen SOAP-Zugriff TRemotable sein muss!!! das "FELD" bzw. die Subklasse "OXID" kreiert und mit einem Wert befüllt...

Code:

  aArt[iDX].OXID:=TXSstring.Create;
  aArt[iDX].OXID.XSToNative('05848170643ab0deb9914566391c0c63');

und damit's lesbarer wird möchte ich gerne

Code:

  OXWrite('OXID',iDX,'05848170643ab0deb9914566391c0c63');

aufrufen können, wobei die Procedure OXWrite ja nix anderes machen soll als die 2 Zeilen oben zu ersetzen, und zu wissen, dass jetzt
aArt[iDX].OXID angesprochen werden soll.... Nur das krieg ich irgendwie nicht hin.

Ich würde einfach nur gerne den Feldnamen übergeben, den Index des Array und den Wert. Und nur daran scheiterts, da ich nicht weiss WIE ich den Feldnamen so übergeben kann, dass ich ihn mit dem (globalen) Array verbinden kann...

Wenn ich aArt{[DX].OXID als ganzes übergebe (nämlich gleich als TXSString definiert) kann ich zwar zugreifen, aber es erstellt mir die Subklasse irgendwo, aber nicht in meinem Array...

@Lenny: oja, lesen können wir voraussetzen, sogar Englisch. Aber wie Du richtig vermutet hast hab ich das Buch nicht, da ich mit einem gratis D7 programmiere und dieses Projekt für einen Bekannten auf seinem D2010 erstelle.

greetz, Erwin J.

[DeddyH]

Kurzes Beispiel: gegeben sei die Klasse TPerson mit den Feldern Name und Vorname und ein dynamisches Array davon. Ursprungscode:

Delphi-Quellcode:

SetLength(Personen, Length(Personen) + 1);
Personen[High(Personen)] := TPerson.Create;
Personen[High(Personen)].Vorname := 'Hans';
Personen[High(Personen)].Name := 'Wurst';
SetLength(Personen, Length(Personen) + 1);
Personen[High(Personen)] := TPerson.Create;
Personen[High(Personen)].Vorname := 'Reiner';
Personen[High(Personen)].Name := 'Zufall';
SetLength(Personen, Length(Personen) + 1);
Personen[High(Personen)] := TPerson.Create;
Personen[High(Personen)].Vorname := 'Machmal';
Personen[High(Personen)].Name := 'Dietürzu';

Dann kann man das kürzen zu:

Delphi-Quellcode:

procedure AddPerson(const AVorname, AName: string);
begin
  SetLength(Personen, Length(Personen) + 1);
  Personen[High(Personen)] := TPerson.Create;
  Personen[High(Personen)].Vorname := AVorname;
  Personen[High(Personen)].Name := AName;  
end;

...

AddPerson('Hans', 'Wurst');
AddPerson('Reiner', 'Zufall');
AddPerson('Machmal', 'Dietürzu');

[Mikkey]

Zitat:

Zitat von Joerginger (Beitrag 1232707)

Nun würde ich gern ein bekanntes Feld (z.B. 'OXID') einer bekannten Klasseninstanz (aArt[index]) einer Prozedur übergeben um ebendort in dieser Prozedur auf selbiges Feld zuzugreifen, so wie ich es auch im aufrufenden Code kann... Brauche ich dazu wirklich die RTTI?

Vielleicht ist die Aufgabenstellung auch zu simpel um richtig verstanden zu werden :stupid:

Delphi-Quellcode:

procedure SetValue(var oFld: TWaswoasDennI; value: string);
begin
  oFld := TWaswoasDennI.Create();
  oFld.SetValue(value);
end;

Du musst schlicht und einfach die Referenz als 'var' übergeben.

[Joerginger]

@DeddyH: Ja, könnte man kürzen, aber leider hat beim Oxid-eShop der Artikelstamm (ohne eventuelle Indivs) 113 Felder, da wäre der Prozeduraufruf ziemlich lang...

@Mikkey: Genau sowas hätte ich mir vorgestellt! Und stimmt, eigentlich doch ganz einfache Anforderung an Delphi?

Leider tuts so doch noch nicht:
Fehler: E2197: Konstantenobjekt kann nicht als Var-Parameter weitergegeben werden.

Ich denke, das Problem ist teilweise auch dass es sich bei allen 113 Feldern nicht um strings, booleans, integers oder doubles handelt, sondern um die nilable Delphi-Klassen (TXSString, TXSInteger, TXSBoolean und TXSDouble).

Fakt ist, dass da 113 x ein Aufruf stattfinden sollte, wo als Parameter einfach der Feldname, der Index und die Daten übergeben werden müssen...

greetz, Erwin J.

[NormanNG]

Hi,

ist zwar nicht ganz so elegant, aber evtl. hilft das hier weiter:

procedure oxWrite( var aField:txString; aValue:String); overload;
begin
aField := txString.Create;
aField.XSToNative(aValue);
end;

procedure oxWrite( var aField:txBoolean; aValue:Boolean); overload;
begin
aField := txBoolean.Create;
aField.asBoolean := aValue;
end;

oxWrite( aArt[idx].OXID, '05848170643ab0deb9914566391c0c63');
oxWrite( aArt[idx].OXTitle, 'Tescht mit ÄÖÜäöüß uns allen Spielis by EJ...');
oxWrite( aArt[idx].OXActive, True);

[Joerginger]

@NormanNG: Das wäre genau das, was ich erreichen wollen würde.

Leider - wenn ich Deinen Code verwende - sagt mir Mr. Compiler mit dem Code E2250 "es gäbe keine überladene Funktion, die man mit diesen Argumenten aufrufen könne"... Ich befürchte es liegt am Versuch der Übergabe von TXSString?

Irgendwoanders hab ich mittlerweile ergooglet, dass es ja setter und getter für diese Quasi-Var's geben könne und von daher ein Zugriff mit var / out nicht möglich / sehr unpraktikabel sei...

Heut' ist echt net mein Tag :lol:

greetz, Erwin J.

[DeddyH]

Man kann keine Properties als Var-Parameter übergeben, siehe gepostete Fehlermeldung. Was aber ginge:

Delphi-Quellcode:

function oxWrite(const aValue:String): txString;
begin
  Result := txString.Create;
  Result.XSToNative(aValue);
end;

aArt[idx].OXID := oxWrite('05848170643ab0deb9914566391c0c63');

Normalerweise bin ich ja kein Freund von Objekten als Rückgabewert, aber hier überseh ich das einfach mal.

[NormanNG]

OK, das geht nicht mit properties.

Dann verwende doch einfach Funktionen:


function oxWrite( aValue:string):txString; overload;
begin
Result := txString.Create;
Result.XLSToNative := aValue;
end;

function oxWrite( aValue:Boolean):txBoolean; overload;
begin
Result := txBoolean.Create;
Result.asBoolean := aValue;
end;



// oxWrite( aArt[0].OXID, 'Test');
aArt[0].OXID := oxWrite('123');
aArt[0].OXTitle := oxWrite('Title');
aArt[0].OXActive := oxWrite(true);

[Joerginger]

@Norman / DeddyH: genau so tut's!

Genial. Hätte ich doch auch selber draufkommen können :cyclops:

Letzte Frage zum Tage noch: Wenn ich Result als TXSString / TXSBoolean ode so (eben eine Klasse) "create" und hernach mit einem Wert versehe... Löscht (destroyed) sich da der Rückgabewert selbstständig sobald die Function den Focus verliert? Wegen SpeicherLeaks warads... Ich wüsst jetzt auf die Schnelle auch keinen Weg eine Result zu knicken?

greetz, Erwin J.

[DeddyH]

Das wäre schön blöd, wenn die Instanzen anschließend automatisch freigegeben würden. Dem ist aber nciht so, was auch bedeutet, dass Du für den Speicher selbst verantwortlich bist. Falls nichts dagegen spricht, kannst Du Dein dynamisches Array ja gegen eine TObjectlist austauschen, die ist erstens effizienter und gibt die enthaltenen Objekte optional automatisch frei (OwnsObjects-Parameter im Konstruktor).

[Joerginger]

Hmmm, heute steh' ich glaub ich echt auf dem Schlaucherl?

Eine function hat einen Result-Wert. Selbigen verwende ich in diesem Fall so, dass ich Result:=TXSString.create fahre und hernach einen Wert mit Result.XSToNative('bla bla') zuweise. Und genau dieses Result (eigentlich ja eine Semi-Variable) ist mein Problem?

Weil den Wert / Status von diesem Result übergebe ich doch mittels

Code:

aArt[iDX].OXID:=oxWrite('bla bla');

ungespitzt an mein Array weiter.

OK, dann ist der Inhalt von Result übergeben, die Fackel trägt ein Anderer. ABER: was passiert jetzt mit besagtem Result aus der aufgerufenen Funktion? Nur mit dieser Semi-Variable meine ich? Die hat doch ihre Schuldigkeit getan und dann sollte sie sich doch selber destroyen? Oder nicht? Weil wenn ich sagen wir mal 3.000 Artikel aus einer Warenwirtschaft zum Oxid hochschnalze, und dabei pro Artikel im Schnitt 60 Felder übertragen muss hätte ich 180.000 kleine Results im Speicher herumwuseln die ich nicht mag :evil:

@DeddyH: Kannst Du mir zum Thema ObjectList noch ein paar Gedanken dalassen? Ich verwende das Array nämlich weils der WSDL-Importer so bastelt. D.h. es gibt eine Klasse Article, und Articles ist ein Array of Article. Und der Article hat die ganzen 113++ "Felder".

Den Speicher im Array gebe ich entweder mit setLength(aArt,0) frei? Oder muss ich durchiterieren und aArt[iDX].destroyen?

greetz, Erwin J.

[DeddyH]

Mit dem SetLength auf 0 gibst Du nur den Speicher frei, den das Array belegt, nicht aber die enthaltenen Objekte. Da wirst Du schon vorher durchiterieren müssen, auf Speicherlecks testen kann man, indem man z.B. in der *.dpr als erste Zeile nach dem "begin" ReportMemoryLeaksOnShutdown auf true setzt (ab Delphi 2006 IIRC, ansonsten FastMM nachinstallieren).

[Blup]

Zitat:

Zitat von Joerginger (Beitrag 1232761)

Hmmm, heute steh' ich glaub ich echt auf dem Schlaucherl?

Eine function hat einen Result-Wert. Selbigen verwende ich in diesem Fall so, dass ich Result:=TXSString.create fahre und hernach einen Wert mit Result.XSToNative('bla bla') zuweise. Und genau dieses Result (eigentlich ja eine Semi-Variable) ist mein Problem?

Result ist eine ganz normale Variable, diese verweist auf ein Object(Instanz einer Klasse) die in dieser Funktion erzeugt wurde.

Zitat:

Zitat von Joerginger (Beitrag 1232761)

Weil den Wert / Status von diesem Result übergebe ich doch mittels

Code:

aArt[iDX].OXID:=oxWrite('bla bla');

ungespitzt an mein Array weiter.

Du wählst über iDX ein Artikelobjekt aus deinem Array und weist einem Feld dieses Artikelobjekts die Adresse des erzeugten Feldobjekts zu.
Hier wird nur die Adresse kopiert, Result und aArt[iDX].OXID verweisen auf das selbe Objekt, Result wird nicht mehr benötigt.
Für die Freigabe des Objektes, auf das OXID verweist, ist ab jetzt das Artikelobjekt verantwortlich. Das hast du hoffentlich im Destructor Destroy berücksichtigt.

Zitat:

Zitat von Joerginger (Beitrag 1232761)

OK, dann ist der Inhalt von Result übergeben, die Fackel trägt ein Anderer. ABER: was passiert jetzt mit besagtem Result aus der aufgerufenen Funktion? Nur mit dieser Semi-Variable meine ich? Die hat doch ihre Schuldigkeit getan und dann sollte sie sich doch selber destroyen? Oder nicht? Weil wenn ich sagen wir mal 3.000 Artikel aus einer Warenwirtschaft zum Oxid hochschnalze, und dabei pro Artikel im Schnitt 60 Felder übertragen muss hätte ich 180.000 kleine Results im Speicher herumwuseln die ich nicht mag :evil:

Natürlich existieren dann in der Summe 3000 Artikelobjekte und jedes hat seine eigenen Feldobjekte.

Zitat:

Zitat von Joerginger (Beitrag 1232761)

@DeddyH: Kannst Du mir zum Thema ObjectList noch ein paar Gedanken dalassen? Ich verwende das Array nämlich weils der WSDL-Importer so bastelt. D.h. es gibt eine Klasse Article, und Articles ist ein Array of Article. Und der Article hat die ganzen 113++ "Felder".
Den Speicher im Array gebe ich entweder mit setLength(aArt,0) frei? Oder muss ich durchiterieren und aArt[iDX].destroyen?

greetz, Erwin J.

Wenn du nicht einzeln freigeben willst, speichere die Artikelobjekte in einer TObjectList, die kümmert sich um die Freigabe (wenn sie selbst freigegeben wird). Wo wird das Array den eigentlich benötigt?

[Joerginger]

Das Array übergibt alle Datensätze an den Oxid-Shop, bzw. alle zu ändernden Daten, in diesem Beispiel die Artikel. Gibt's aber auch für User, Attribute, Kategorien, Gruppen etc... Zu diesem Behufe wird das Array (bei größeren Mengen segmentiert) gefüllt und dann mittels SOAP-Schnittstelle an die Gegenstelle im Oxid übergeben. Das war sowieso schon eine Turbogeniale Kagge, das alles zum laufen zu bringen. Zuerst hab ich's in meinem D7 programmiert bis wir draufgekommen sind dass die SOAP-Umsetzung in D7 echt krank ist (alle Umlaute haben die Felder terminiert, z.B.). Danach hab ich das ganze nochmals im D2010 von einem Bekannten/Kunden gebastelt, da waren dann die nilables unser Thema... Weil wenn ich nur 2 Felder (OX-ID und Titel) raufgespielt habe war im Oxid der restliche Satz leer (also alle numerischen Werte auf 0, alle booleans auf False, alle Strings "")... Echt geil.

Prinzipiell frag ich mit Delphi per WSDL-Importer die SOAP-Schnittstelle ab und bekomme exakt diese Aufrufsbeschreibung, eben mit Array. Und mit der TObjectList muss ich mich noch beschäftigen... Ich werds mal googlen.

Mein Destruktor ruft für jedes einzelne TXS-Objekt (egal ob TXSBoolean, TXSString, TXSInteger oder TXSDecimal) ein

Code:

  SysUtils.FreeAndNil(FELDNAME);

auf, beim Artikel eben über 113 Felder, d.h. wenn ich einen Artikel destroye macht er automatisch alle (verwendeten) Felder platt. Das hab ich mittlerweile ausprobiert und tut auch...

Was ich noch nicht gefunden habe sind ominöse Speicherleaks hinsichtlich Unicode Strings??? Die Medlung sagt UnicodeString x 2 und nächste Zeile UnicodeString x 1. Aber das ist eine andere Baustelle und noch nicht vordringlich.

Hab heute hier wieder mal extrem viel gelernt und bedanke mich herzlichst bei allen Beteiligten!!! DANKE!!!

greetz, Erwin J.