Freigeben von Objekten einer Function

[Delbor]

Hi Scharfe Mieze

Zitat:

ich habe ein generische OBjektliste vom Typ TTGMessage , in der sich entweder eine Message oder eine edited_message befindet.(alle sind vom Typ TTGMessage)

Objectlisten haben ein Boolean-Property OwnsObjects, mit dem du bestimmen kannst, dass sie sämtliche aufgelisteten Objekte freigibt, wenn sie selbst freigegeben wird.

Aber Vorsicht: Objekte, die sich in der Liste befinden und die beim Erzeugen einem Owner zugewiesen werden, wollen von diesem und allenfalls der Objektliste freigegeben werden.

Gruss
Delbor

[ScharfeMietze]

{ The OwnsObjects property is set by default to true -- the list will free the owned objects automatically. }
Genau das ist ja der Hintergedanke.mich eben nicht drum kümmern zu müssen.


Was mir manchmal nicht schlüssig ist wann wer wie welches objekt besitzt und wann es durch OwnsObjects befreit wird ..
Was ist wenn ich das Result der fuction einer weiteren objektliste übergebe? Wer hat dann wann was?

Hintergrund ist der, das später in (verschiedenen) Task je nach Inhalt weiterverarbeitet werden soll. Die Task sollen ihre eigenen Objektlisten haben.

Daher kann eine TGMessage aus den originalen Telegramm results (FTGResults(objekliste)) in weiteren/mehreren Objektlisten auftauchen.
Die Task prüfen Quasi ob ihre Objektliste was enthält und wenn ja arbeiten sie es ab.
So ist bisher mein Plan.

Daher hoffe ich das ihr mir die Frage beantworten könnt wann wer Besitzer des Objekts aus der "Hauptliste" FTGResults (generic Object Liste) ist und wann es wie durch OwnsObjects befreit wird. Wenn es immer FTGResults ist, wäre es einfach da ich diese dann einfach erst befreie wenn alle Task fertig sind.... Mindmap siehe Bild

[Olli73]

Wenn du die weiteren Listen auch auf OwnsObjects stellst hast du ein Problem, da die erste Liste, die freigegeben wird (oder wenn ein Objekt aus der Liste gelöscht wird) das Objekt löscht und die andere Liste dann ins Leere greift. Es gibt also nicht sowas wie einen (Haupt-)Eigentümer.

Funktionieren würde das nur bei den mobilen OS, dort wird das über Referenzzählung gelöst, erst nach dem Auflösen der letzten Referenz wird freigegeben.

[ScharfeMietze]

Gut, das ist ja planbar. Da Telegramm max 100 Updates ausspuckt kann es mit einer Referenzzählung versehen werden pro Aufgabe zähle hoch, ist die Aufgabe erledigt ziehe 1 ab ist der Referenzzähler 0 lösche es aus der Hauptliste.
die restlichen listen bekommen ownsobject false.....
dann muss auch nur die Hauptliste permanent bestehen ..

[himitsu]

Außerdem:

Warum ignorierst du böswillig die Fehlermeldungen deines Compilers?

Create, bzw. irgendeine Initialisierung gehört IMMER vor das Try, denn sonst ist diese Variable im Except/Finally nicht initialisiert, welches dir der Compiler auch gesagt hat.

Delphi-Quellcode:

Result := TTGMessage.Create;
try
  ...
except // ebenso bei finally
  Result.Free;
  raise;
end;

Delphi-Quellcode:

Result := nil;
try
  Result := TTGMessage.Create;
  ...
except // ebenso bei finally
  Result.Free;
  raise;
end;

[ScharfeMietze]

Hmpf... Da bin/war ich beim markieren und "umgeben mit" schlicht zu hoch gerutscht.
natürlich danke für den Hinweis