Auf Klassenvariablen indiziert zugreifen?

[Blup]

Zitat von 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?

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

Zitat von Joerginger:

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 von Joerginger:

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

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

Zitat von Joerginger:

@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.