Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Eleganter Ersatz für TList und Objekte unter FMX-Platformen? (https://www.delphipraxis.net/187755-eleganter-ersatz-fuer-tlist-und-objekte-unter-fmx-platformen.html)

Harry Stahl 30. Dez 2015 22:08

Eleganter Ersatz für TList und Objekte unter FMX-Platformen?
 
Liste der Anhänge anzeigen (Anzahl: 1)
Bin gerade dabei eine meiner Anwendungen nicht nur für Windows, sondern auch für MAC, Android und IOS bereit zu stellen. Allerdings gehe ich mal versuchsweise einen anderen Weg als sonst: Nicht der volle Umschwung zu FMX mit einer Vollkonvertierung, sondern (zumindest eine Zeit lang) noch die Windows-Version als VCL-Projekt weiterzuführen, aber mit einer gemeinsamen Source-Code Basis auch die MAC-, Android und IOS-Version zu bestücken.

MAC-Version ist als Beta schon fertig (bei Interesse siehe hier).

Was mir leider erst jetzt bei der Bearbeitung der Android-Version (siehe anlg. Screenshot vom Device) wieder einfiel, ist die ARC-Thematik und die Verwendung von TList mit Objekten.

Stevie hatte hier schon mal etwas ausgeführt: http://www.delphipraxis.net/1266711-post5.html

Meine Frage ist nun: Wie könnte ein eleganter Weg aussehen, um ein TTermin-Objekt, das bisher in einer TList-Liste verwaltet wird, durch eine andere Lösung zu ersetzen, die gleichwohl auf allen Plattformen (also incl. VCL-Windows) verwendet werden kann

UND

möglichst so eingeführt wird, dass ich an allen Stellen im Source-Code keine Änderungen vornehmen muss (denn es wären viel tausend Stellen)?

Bisher verwende ich das Object und die Liste unter Windows (und MAC) ungefähr so:

Delphi-Quellcode:
TTermin = class (TObject)
    Deleted: Integer;    // wird nicht in Datei gespeichert; <> 0 ist gelöscht
    Markiert: Boolean; // ab Version 5 (wird nicht in Datei gespeichert)

{1} ID : String;
    DTyp : Integer; {0 = Termin, 1 = Aufgabe }
    Tag: String;
    .... usw.

Im Source-Code wird das Objekt halt oft in dieser Art verwendet:

Delphi-Quellcode:
procedure Tfrm_Main.Fill2WeeksList (day, month, year: Word);
var
  Y, D, F, P, xl, L, M: Integer;
  Tag, RepeatDay, S, sNew: String;
  tm: tTermin;
begin
  for L := 1 to TerminList.Count-1 do begin
    try
      tm := TTermin (TerminList[L]);
      if tm.tag = Today // usw.
Oder so beim Erzeugen des Objects:

Delphi-Quellcode:
var
  TerminList: TList;

begin
  tm := tTermin.Create;
  TerminList.Add (tm);
  /// weiter mit tm arbeiten
Jemand einen zündende Idee?

SProske 30. Dez 2015 22:14

AW: Eleganter Ersatz für TList und Objekte unter FMX-Platformen?
 
Spricht etwas gegen die Verwendung der generischen TObjectList (TObjectList<TTermin>)?

Harry Stahl 30. Dez 2015 22:26

AW: Eleganter Ersatz für TList und Objekte unter FMX-Platformen?
 
Hätte vielleicht noch erwähnen sollen, dass ich kaum Erfahrung mit Generics habe.

Würde ich dann einfach nur die unit

System.Generics.Collections,

hinzufügen und

TerminList: TList;

durch

TerminList: TObjectList<TTermin>;

ersetzen?

Und die TObjectList könnte ich verwenden wie die TList?

Wie würde ich z.B. die Liste erzeugen?

Sir Rufo 30. Dez 2015 22:34

AW: Eleganter Ersatz für TList und Objekte unter FMX-Platformen?
 
Nimm
Delphi-Quellcode:
type
  TTerminList = TObjectList<TTermin>;

TerminList := TTerminList.Create();

Harry Stahl 30. Dez 2015 22:40

AW: Eleganter Ersatz für TList und Objekte unter FMX-Platformen?
 
Danke, an dieser Stelle schon mal einfacher, als gedacht:)

Harry Stahl 30. Dez 2015 22:46

AW: Eleganter Ersatz für TList und Objekte unter FMX-Platformen?
 
Gut, jetzt habe ich noch Stellen, wo z.B. die TList als Parameter verwendet wird:

Delphi-Quellcode:
procedure SaveDatesFile (FName: String; DatesList: TList);
Das könnte ich ja z.B. per Refactoring ändern.

Oder gäbe es noch was eleganteres?

z.B. TList irgendwie als Typ auf TTErminList "umbiegen", per Typendeklaration? Wäre das sinnvoll / möglich, mit Gefahren verbunden? Es ist die einzige TList, die ich in diesem Projekt verwende.

Wobei... gerade mal nachgesehen, habe nur 2 Vorkommen von TList als Parameter, da brauche ich wohl noch nicht mal das Refactoring, um das zu ändern...

Sir Rufo 30. Dez 2015 22:50

AW: Eleganter Ersatz für TList und Objekte unter FMX-Platformen?
 
Du hättest schon im alten Projekt definieren sollen
Delphi-Quellcode:
type
  TTerminList = TList;
um dann überall nur mit diesem
Delphi-Quellcode:
TTerminList
zu arbeiten ;)

Harry Stahl 30. Dez 2015 23:04

AW: Eleganter Ersatz für TList und Objekte unter FMX-Platformen?
 
Ja, da hast Du wohl recht. Die ersten grundlegenden Definitionen (kann man wohl ein wenig sehen) stammen noch aus ca. 1995...

Ich kann nun zwar das wie sonst auch machen (zumindest gerade mal unter Windows getestet):

Delphi-Quellcode:
for L := 0 to TerminList.count - 1 do begin
  TTermin(TerminList[L]).Free;
end;
Weil Delphi das wohl selber regelt:

Delphi-Quellcode:
procedure TObject.Free;
begin
// under ARC, this method isn't actually called since the compiler translates
// the call to be a mere nil assignment to the instance variable, which then calls _InstClear
{$IFNDEF AUTOREFCOUNT}
  if Self <> nil then
    Destroy;
{$ENDIF}
end;
Ein einfaches

Delphi-Quellcode:
Terminlist.clear;
lässt das Programm aber abstürzen.

Warum ist das so, bzw. wie setze ich die Liste wieder auf Null Elemente zurück?

Sir Rufo 30. Dez 2015 23:07

AW: Eleganter Ersatz für TList und Objekte unter FMX-Platformen?
 
Weil eine
Delphi-Quellcode:
TObjectList
/
Delphi-Quellcode:
TObjectList<T>
per default das Lifetime-Management der Instanzen übernimmt ;)

Delphi-Quellcode:
TerminList := TTerminList.Create(); // Verwaltet die Instanzen
TerminList := TTerminList.Create( true ); // Verwaltet die Instanzen
TerminList := TTerminList.Create( false ); // Verwaltet die Instanzen NICHT

SProske 30. Dez 2015 23:08

AW: Eleganter Ersatz für TList und Objekte unter FMX-Platformen?
 
TObjectList<T> hat eine Property OwnsObjects - steht diese auf true, kümmerst sich die Objektliste um die Freigabe der zugehörigen Objekte - steht sie auf false, musst du dich selbst drum kümmern. Verwendest du diese Objekte also an anderer Stelle wieder, sollte OwnsObjects auf false stehen, sonst werdne beim Clear alle Items ge"free"t.


Alle Zeitangaben in WEZ +1. Es ist jetzt 00:13 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz