Die Sache mit dem Listenproperty

[TBx]

Hmm, das finde ich nicht so gut. Damit gibst Du ja die Möglichkeit, dass ein privater Classmember von außen vernichtet werden kann.

Getreu dem Motto, dass jeder seinen eigenen Müll wegräumen soll, erwarte ich dann eine entsprechende Instanz eines TStrings-Nachfahren von außen.

[DeddyH]

Naja, wer das tut, ist ja selber Schuld. Oder gibst Du z.B. TComboBox.Items auch frei? ;)

[Delbor]

Hi zusammen

Zitat:

Ich würde vermutlich Lazy Initialization benutzen: ein privates Feld vom Typ TStrings oder gleich TStringList.

Eigentlich habe ich ja genau dies - mit TStrings statt TStringlist - umzusetzen versucht und erstmal eine AV erhalten.

Zitat:

Was genau soll das Result.Clear; bewirken? An der Stelle ist doch Result noch gar nicht definiert...
...
Zitat von Delbor:
Andrerseits sollte es keinen Schaden anrichten.

Ähm - doch! Da Result an der Stelle nicht definiert ist, kann alles Mögliche drin stehen (auch nil). In jedem Fall ist der Aufruf Result.Clear zu entfernen. Schau mal, ob es dann funktioniert.

Nach der Antwort von Uwe Raabe in Beitrag sechs und da es seit Entfernung des "Result:=True;" genau das tut, was es sollte, bin ich überzeugt, dass ich FContentmastertables auch als TStrings deklarieren könnte. Das würde auch deinem verlinkten (bis auf TStringlist) Beispiel unter Lazy Initialization entsprechen.

@sakura:

Zitat:

Mal grundsätzlich ist das so kein guter Ansatz:

Wenn mehrere Threads gleichzeitig auf die Eigenschaft zugreifen, wirst Du sehr seltsame Ergebnisse bekommen

Es gibt in dieser Anwendung nur den einen Thread. Einen zweiten wird es wohl nicht geben. Denn trotz dem Einsatz von MySQL handelt es sich um eine Desktopanwendung. Und auch wenn es mehrere Threads neben dem Haupttread geben sollte. müssten diese in einer Criticalsection auf den Speicher zugreifen. Dazu käme wohl noch der Zugriff auf ein Objekt...

Zitat:

Ändert sich das Ergebnis so rasant, dass es Sinn mach mit jedem Zugriff alles neu zu ermitteln

Das Ergebnis dient dazu, die Tabellen der DB anzuzeigen. Das Property soll die Tabellen nach oben zur Verfügung stellen; die Gui muss nur daruf zugreifen. Ich weiss: dazu gibt es bei Firedac die Connection-Komponente.

Zitat:

Macht evtl. eine lokale StringListe mehr Sinn/bzw als Rückgabetyp ein Array?

Da FContentmastertables ein privates Feld des Datenmoduls ist und in dessen Create-bzw Destroy-Prozedure erzeugt/gelöscht wird, macht eine private Liste keinen Sinn, ausser dass sie bei jedem Zugriff erstellt/zerstört werden müsste.

Gruss
Delbor

[sakura]

Hi

Zitat:

Zitat von Delbor (Beitrag 1363083)

Es gibt in dieser Anwendung nur den einen Thread. Einen zweiten wird es wohl nicht geben. Denn trotz dem Einsatz von MySQL handelt es sich um eine Desktopanwendung. Und auch wenn es mehrere Threads neben dem Haupttread geben sollte. müssten diese in einer Criticalsection auf den Speicher zugreifen. Dazu käme wohl noch der Zugriff auf ein Objekt...

Eine gute Richtlinie ist es aber immer so zu entwickeln, als könnten solche Informationen an mehreren Stellen gleichzeitig gebraucht werden, das macht spätere Erweiterungen leichter. Auch bei Desktopanwendungen ist Multi-Threading schon lange keine Ausnahme mehr.

Zitat:

Zitat von Delbor (Beitrag 1363083)

Das Ergebnis dient dazu, die Tabellen der DB anzuzeigen. Das Property soll die Tabellen nach oben zur Verfügung stellen; die Gui muss nur daruf zugreifen. Ich weiss: dazu gibt es bei Firedac die Connection-Komponente.

Warum dann lädst Du die Liste der Tabellen mit jeder Anfrage, anstatt nur einmal. Ändern werden sich die Tabellen ja wohl kaum...?

Zum Thema Rückgabewert, wenn irgendein Aufrufer die Liste zerstört (Destroy, Free), dann wird es Zugriffsverletzungen geben, entweder später oder beim Beenden. Deswegen die Frage, warum nicht ein Array zurück geben?

...:cat:...

[TBx]

Zitat:

Zitat von sakura (Beitrag 1363089)

Hi
Zum Thema Rückgabewert, wenn irgendein Aufrufer die Liste zerstört (Destroy, Free), dann wird es Zugriffsverletzungen geben, entweder später oder beim Beenden. Deswegen die Frage, warum nicht ein Array zurück geben?
...:cat:...

[Ironie]oooch, das wurde doch schon abgebacken:

Zitat:

Zitat von DeddyH (Beitrag 1363063)

Naja, wer das tut, ist ja selber Schuld. Oder gibst Du z.B. TComboBox.Items auch frei? ;)

[/Ironie]

[sakura]

Zitat:

Zitat von TBx (Beitrag 1363091)

[Ironie]oooch, das wurde doch schon abgebacken:

Zitat:

Zitat von DeddyH (Beitrag 1363063)

Naja, wer das tut, ist ja selber Schuld. Oder gibst Du z.B. TComboBox.Items auch frei? ;)

[/Ironie]

Ich weiß, und auch das finde ich persönlich eher unschön, ist aber den alten Zeiten zu danken und lässt sich heute auch nicht mehr ändern...

...:cat:...

[TBx]

@sakura: :thumb:

[DeddyH]

Damit es Ruhe hat:

Delphi-Quellcode:

type
  TDingens = class
  private
    FTablenames: TStringList;
    function GetTablenames(Index: integer): string;
    function GetTablenameCount: integer;
  public
    constructor Create;
    destructor Destroy; override;
    property TablenameCount: integer read GetTablenameCount;
    property Tablenames[Index: integer]: string read GetTablenames;
  end;

...

constructor TDingens.Create;
begin
  FTablenames := TStringList.Create;
  FillTablenamesFormSomewhere(FTablenames);
end;

destructor TDingens.Destroy;
begin
  FTablenames.Free;
  inherited;
end;


function TDingens.GetTablenames(Index: integer): string;
begin
  Result := FTablenames[Index];
end;

function GetTablenameCount: integer;
begin
  Result := FTablenames.Count;
end;

Damit kann man dann durch die Liste iterieren, hat aber keinen direkten Zugriff darauf.

[sakura]

Zitat:

Zitat von DeddyH (Beitrag 1363097)

Damit es Ruhe hat

Ach komm, biete doch noch einen Listen-Enumerator an :mrgreen:

...:cat:...

[DeddyH]

*Pff* :tongue: