Memo mag TStringList nicht?

[xSkaschY]

Hallo,

ich versuch gerade ein Memo mit Daten aus einer TStringList zu füttern, jedoch verweigert dat Memo die Annahme mit eifrigen nicht anzeigen.

Warum ich eine Memo mit einer TStringList füllen möchte?

Ich muss die Daten vorher aufbereiten und das ist für mich der "bequemste" weg.


So nun zum Quellcode:

Die Funktion die mir die Daten bereitstellt:

Delphi-Quellcode:

function TConfiguration.getData: TStringList;
var
        i: Integer;
        sBuffer: String;
        aMotdItems: TArray;
        slTemp: TStringList;
begin
        sBuffer := '';
        slTemp := TStringList.Create;
        try
                for i := 0 to slConfig.Count - 1 do begin
                        sBuffer := sBuffer + slConfig[i];
                end;

                sBuffer := Copy(sBuffer, (Pos('{', sBuffer)+1));
                sBuffer := Copy(sBuffer, 0, (Pos('}', sBuffer)-1));


                aMotdItems := explode('"', sBuffer, 0);

                // ich brauch den alten Buffer nicht mehr, also weg damit.
                sBuffer := '';

                for i := 0 to Length(aMotdItems) - 1 do begin
                        if (Trim(aMotdItems[i]) <> ',') and (Trim(aMotdItems[i]) <> '') then  begin

                                // Daten in die Stringlist packen.
                                slTemp.Add(Trim(aMotdItems[i]));
                        end;
                end;
        finally
                // Array verarbeitet, also länge auf 0
                SetLength(aMotdItems, 0);

                // hier gebe hier die ganze StringList als "return" Value an.
                Result := slTemp;

                // Tschüss Stringlist, war schön mit dir zu arbeiten.
                slTemp.Free;
        end;
end;

Und so probiere ich die TStringList in das Memo zu bekommen:

Delphi-Quellcode:

memoConfiguration.Lines := oConfiguration.getData;

Warum zum Teufel mag der des nicht?

Die Stringlist ist mit 5 Werten gefüllt. (Können aber mal mehr oder mal weniger sein.)


LG Toby

[Phoenix]

Delphi-Quellcode:

memo.Lines.Clear;
memo.lines.AddStrings(myStringList);

[DP-Maintenance]

Dieses Thema wurde von "Phoenix" von "Sonstige Fragen zu Delphi" nach "VCL / WinForms / Controls" verschoben.
Und TMemo ist ein Control... und TStringList gehört auch zur VCL.. also eher die andere Sparte.

[freak4fun]

Lines vom Memo sind vom Typ TStrings und nicht vom Typ TStringlist. ;)

[DeddyH]

Ich würde das anders machen:

Delphi-Quellcode:

procedure TConfiguration.getData(const sList: TStrings);

Als sList kannst Du dann direkt Memo.Lines angeben.

[xSkaschY]

Danke DeddyH,

so werd ich das auch machen da

Delphi-Quellcode:

// hier gebe hier die ganze StringList als "return" Value an.
Result := slTemp;

// Tschüss Stringlist, war schön mit dir zu arbeiten.
slTemp.Free;

slTemp.Free zerstört irgendwie die Rückgabe.


Edit: Jup Funktioniert so bestens! :-) Danke!

[DeddyH]

Klar, Du müsstest die Stringliste dann außerhalb der Funktion wieder freigeben. Das ist sehr unschön und wird gerne mal vergessen.

[xSkaschY]

Joa das wirklich sehr unschön, die von dir vorgeschlagene Variante ist recht gut, wusste nicht das man des auch so übergeben kann.

Das erspart einem eine Menge Arbeit! :-)

[RavenIV]

Zitat:

Zitat von DeddyH

Ich würde das anders machen:

Delphi-Quellcode:

procedure TConfiguration.getData(const sList: TStrings);

Als sList kannst Du dann direkt Memo.Lines angeben.

Das ist der Beste Weg.
Irgendwelche Objekte in Funktionen erzeugen und als Returnwert zurückgeben ist immer fehleranfällig.
Am Besten solche Objekte als var-Parameter oder besser noch out-Parameter übergeben lassen.
Dann muss / kann sich die aufrufende Procedure um das Erstellen und Zerstören kümmern.

[Muetze1]

Moin!

Zitat:

Zitat von RavenIV

Irgendwelche Objekte in Funktionen erzeugen und als Returnwert zurückgeben ist immer fehleranfällig.

Und falsch, da man niemals die Grundregel erfüllen kann, Objekte auf der gleichen Ebene freizugeben wo sie erzeugt werden.

Zitat:

Zitat von RavenIV

Am Besten solche Objekte als var-Parameter oder besser noch out-Parameter übergeben lassen.

Wenn die aufrufende Funktion die Instanz erstellt ist genau beides eine riesige Fehlerquelle. Mit dem VAR erlaubst du dem aufgerufenen explizit die Instanz zu verändern - also eine ganz andere zurück zu geben als im übergeben wurde. Von daher ist hier const deutlich besser geeignet.

Zitat:

Zitat von RavenIV

Dann muss / kann sich die aufrufende Procedure um das Erstellen und Zerstören kümmern.

Und mit dem kann/muss ist es wieder nicht eindeutig, wer sich nun kümmern muss. Und die aufrufende Procedure kann sich bei out definitiv nicht darum kümmern, damit versaubeutelst du schon die aussen erstellte Instanz, da diese niemals reingereicht wird. Bitte informier dich über den Unterschied von out und var!

Gruss
Muetze1

[RavenIV]

Zitat:

Zitat von Muetze1

Zitat:

Zitat von RavenIV

Am Besten solche Objekte als var-Parameter oder besser noch out-Parameter übergeben lassen.

Wenn die aufrufende Funktion die Instanz erstellt ist genau beides eine riesige Fehlerquelle. Mit dem VAR erlaubst du dem aufgerufenen explizit die Instanz zu verändern - also eine ganz andere zurück zu geben als im übergeben wurde. Von daher ist hier const deutlich besser geeignet.

Die Funktion soll ja grad dieses Objekt verändern, weil sie damit etwas zurückgeben soll.
Das Schlüsselwort "const" ist hierfür denkbar ungeeignet, weil dann die Funktion nichts verändern darf.

Wie auch immer, der Original-Author hat Denkanstösse bekommen.
Alles Weitere muss er nun selber bewerkstelligen.

[Apollonius]

Raven, dieser Code kompiliert trotz const fehlerfrei:

Delphi-Quellcode:

type
TMyObject = class
  fField: Integer;
end;

procedure Proc(const Obj: TMyObject);
begin
  Obj.fField := 5;
end;

Da Objekte Zeiger sind, bezieht sich das const nicht auf Felder und entsprechend auch nicht auf Methoden und Eigenschaften.

[Luckie]

Zitat:

Zitat von xSkaschY

Warum zum Teufel mag der des nicht?

Beim nächsten mal wäre eine etwas präzisere Fehlerbeschreibung inklusive genauer Fehlermeldung wünschenswert. :?

[DeddyH]

IMHO sollte man Objektinstanzen immer als const-Parameter übergeben. Wie schon korrekt bemerkt wurde, sind es ja intern Pointer, so dass sich die dahinterliegenden Felder trotzdem bearbeiten lassen. Ansonsten wären z.B. solche Dinge möglich:

Delphi-Quellcode:

procedure TfrmMain.Machwas(sList: TStrings);
begin
  //Code zum Ändern der Strings
  sList := ListboxBla.Items;
end;

[RavenIV]

Zitat:

Zitat von Apollonius

Raven, dieser Code kompiliert trotz const fehlerfrei:

Delphi-Quellcode:

type
TMyObject = class
  fField: Integer;
end;

procedure Proc(const Obj: TMyObject);
begin
  Obj.fField := 5;
end;

Da Objekte Zeiger sind, bezieht sich das const nicht auf Felder und entsprechend auch nicht auf Methoden und Eigenschaften.

OK, hab ich eingesehen.
Aber das const ist dennoch für einen ungeübten Betrachter verwirrend.

[Muetze1]

Moin!

Zitat:

Zitat von RavenIV

OK, hab ich eingesehen.
Aber das const ist dennoch für einen ungeübten Betrachter verwirrend.

Das ist der große Unterschied in der Definition der Bedeutung von const in Delphi. C++ und C# Programmierer haben oft genau diesen Trugschluß (neben CodeGear selbst: QC #42782).

Gruss
Thomas