Letzte Stelle eines Strings anwählen

[Informatik-LK]

Hallo Leute,

ich bins mal wieder, euer Delphi-Noob.
Ich habe kleine Fortschritte gemacht, denn ich habe schon einen Süßigkeitenautomaten und einen Einarmigen Banditen (bis auf einen Fehler) komplett selber programmiert. Trotzdem bin ich immer noch ein blutiger Anfänger.
Jetzt habe ich wieder eine klitzekleine Frage:
Wie wähle ich die letzte Stelle eines Strings an? Also was muss anstatt der Fragezeichen in der eckigen Klammer stehen?

Delphi-Quellcode:

Memo1.Text[??];

MfG

Informatik-LK

[DeddyH]

Versuch es mal mit

Delphi-Quellcode:

Memo1.Text[Length(Memo1.Text)];

[dominikkv]

Delphi-Quellcode:

Memo1.Text[Length(Memo1.Text)-1];

[Informatik-LK]

Vielen Dank! Die Antwort von DeddyH hat gestimmt.

Gruß

[dominikkv]

oha bei Strings ist das ja anders^^
von 1 bis Length()

[SirThornberry]

bitte immer bedenken das ein Memo auch leer sein kann. Also vorher besser mal überprüfen.

[Hawkeye219]

Hallo,

wer schlau ist, der verwendet die Funktion RightStr aus der Unit StrUtils.

Gruß Hawkeye

[marabu]

Hallo,

was soll das denn werden?

Das letzte Zeichen dürfte sehr oft #10 sein.

Freundliche Grüße

[Muetze1]

Ich werfe dann auch nochmal AnsiLastChar() in die Runde. Nachteil: Bei einem leeren String würde die PChar Konvertierung ein Nil bringen und AnsiLastChar() mit einer AV abrauchen. Also diese Funktion nur, wenn der String definitv nicht leer ist.

[DeddyH]

*Hehe* An AnsiLastChar hatte ich auch schon gedacht. Nun müsste man sich eigentlich überlegen, ob man den String nicht erst trimmen möchte, dann die Länge abfragen und dann (falls der String nicht leer ist) AnsiLastChar einzusetzen. Das wäre in meinen Augen der Königsweg (aber ich lasse mich gerne belehren).

[jbg]

Zitat:

Zitat von Muetze1

Nachteil: Bei einem leeren String würde die PChar Konvertierung ein Nil bringen

So so. Hast du etwa die System.pas insbesondere die Funktion _LStrToPChar umgeschrieben und setzt dass nun bei jedem anderen voraus? :mrgreen:

[Muetze1]

Ok, falsche Stelle im Kopf gehabt: Bei einem leerem String gibt AnsiLastChar() einen NIL Pointer zurück und dessen Dereferenzierung zum Vergleich des letzten Chars raucht dann mit einer AV ab.

Wäre es so wie ich es zuvor beschrieben habe, dann müsste meine XMLLib nur noch abrauchen...

[Informatik-LK]

Wow, da habe ich wohl eine rege Diskussion aufleben lassen.
Naja, bei meiner Syntaxprüfung klappt jetzt alles wunderbar bis auf die Überprüfung des vorletzten Zeichens des Strings. Wie kann ich das wieder anwählen?
Wenn ich

Delphi-Quellcode:

Memo1.Text[Length(Memo1.Text)-1];

schreibe, kriege ich eine Fehlermeldung wegen eines Operandentyps. Ich hoffe, ihr habt erneut eine Antwort für mich. :-D

[mkinzler]

Delphi-Quellcode:

s := Memo1.Text[Length(Memo1.Text)-2];

[Informatik-LK]

Hm, damit habe ich mein Problem noch nicht gelöst. Also es geht um eine Syntaxprüfung, wobei der eingegebene Text immer diese Form haben muss: ab <Mein Text> b. Und deswegen wollte ich eben die Bedingung schreiben, dass wenn das vorletzte Zeichen des Strings nicht die Ordnungszahl 32 (ASCII-Tabelle: Leerzeichen) hat, eine Fehlermeldung kommt.

Ich habe es auch schon mit

Delphi-Quellcode:

if not (rightstr(Memo1.Text, 2) = ' b') then

(also dass die letzten beiden Zeichen eine Lücke und ein b sind) probiert, aber dann kennt er den Bezeichner rightstr nicht...

[Christian Seehase]

Moin Informatik-LK,

RightStr befindet sich in der Unit StrUtils (zumindest in D7).
Die müsstest Du noch unter Uses einbinden.

Was mir aber aufgefallen ist: Du verwendest mehrfach die Eigenschaft Text von TMemo.
Zugriffe auf diese Eigenschaft sollte man möglichst vermeiden, da sie bei jedem Aufruf erst einmal aus den Lines zusammengesetzt wird. Das drückt, je nach Anzahl der Zeilen im Memo, ganz gewaltig auf die Performance.
In Deinem Anwendungsfall scheint es so, als würdest Du immer mit der letzten Zeile des Memos auskommen, also wäre doch die Abfrage

Delphi-Quellcode:

if RightStr(Memo1.Lines[Memo1.Lines.Count-1],2) = ' b' then

eine Alternative.
Voraussetzung ist hier natürlich, dass mindestens eine Zeile enthalten ist, da es sonst zu einer AV kommt.

[marabu]

Moin Christian,

Zitat:

Zitat von Christian Seehase

... Was mir aber aufgefallen ist: Du verwendest mehrfach die Eigenschaft Text von TMemo. Zugriffe auf diese Eigenschaft sollte man möglichst vermeiden, da sie bei jedem Aufruf erst einmal aus den Lines zusammengesetzt wird. ...

es gibt da einen kleinen, aber feinen Unterschied zu Memo.Lines.Text: Memo.Text besorgt den Text vom unterliegenden Windows Edit Control per WM_GETTEXT, während Memo.Lines.Text als VCL-Funktionalität das von dir beschriebene Aggregationsverhalten an den Tag legt.

Freundliche Grüße

[Muetze1]

Ich muss euch beide enttäuschen:

1. Es gibt keinen Unterschied
2. Er baut in keinem der beiden Fällen die Strings zusammen.

Delphi-Quellcode:

function TMemoStrings.GetTextStr: string;
begin
  Result := Memo.Text;
end;

Bei einem Memo wird der Text direkt vom Control gehalten und die Lines[] Eigenschaft holt die Zeilen mit den Windowsbotschaften direkt vom Control.

Delphi-Quellcode:

function TMemoStrings.Get(Index: Integer): string;
var
  Text: array[0..4095] of Char;
begin
  Word((@Text)^) := SizeOf(Text);
  SetString(Result, Text, SendMessage(Memo.Handle, EM_GETLINE, Index,
    Longint(@Text)));
end;

Der angegebene Quelltext ist (c) Copyright by Borland/CodeGear.

Bei einer ListBox würdet ihr teilweise Recht haben. Teilweise nur, weil die ListBox ihre Text Eigenschaft nicht veröffentlicht.

[Sharky]

Zitat:

Zitat von Muetze1

Ich muss euch beide enttäuschen:

1. Es gibt keinen Unterschied
2. Er baut in keinem der beiden Fällen die Strings zusammen.
...

Hai Thomas,

mein Delphi sagt mit bei der TMemo.Lines.Text als Getter:

Delphi-Quellcode:

function TStrings.GetTextStr: string;
var
  I, L, Size, Count: Integer;
  P: PChar;
  S, LB: string;
begin
  Count := GetCount;
  Size := 0;
  LB := LineBreak;
  for I := 0 to Count - 1 do Inc(Size, Length(Get(I)) + Length(LB));
  SetString(Result, nil, Size);
  P := Pointer(Result);
  for I := 0 to Count - 1 do
  begin
    S := Get(I);
    L := Length(S);
    if L <> 0 then
    begin
      System.Move(Pointer(S)^, P^, L);
      Inc(P, L);
    end;
    L := Length(LB);
    if L <> 0 then
    begin
      System.Move(Pointer(LB)^, P^, L);
      Inc(P, L);
    end;
  end;
end;

[marabu]

Hi Stephan,

Thomas hat Recht. Ich bin auch davon ausgegangen, dass es sich bei der Eigenschaft Lines um eine einfache StringList handelt, aber weit gefehlt: Es wird TMemoStrings verwendet und in dieser Klasse wird der Text tatsächlich per WM_GETTEXT besorgt.

Freundliche Grüße

[Muetze1]

Ich arbeite mit Delphi 5 (hauptsächlich) und dort implementiert die VCL noch eine TMemoStrings Klasse mit dem o.g. Verhalten. Ich habe nun noch schnell mal D6 und D7 untersucht und kann nun sagen: Ab Delphi 6 wurde das umgestellt auf die Nutzung von TStrings anstatt TMemoLines beim TMemo.

Somit: Bis einschliesslich Delphi 5 macht es keinen Unterschied, aber Delphi 6 ist ein aufwendiger Zugriff.

/EDIT: roter Kasten?

@marabu: Wenn du (laut Profil) Delphi 7 verwendest: woher kennst du denn die TMemoLines? Diese finde ich nicht mehr in der VCL von Delphi 7... :gruebel:

[marabu]

Hallo Thomas,

D5 und D7 implementieren bei mir TCustomMemo so:

Delphi-Quellcode:

types
  TCustomMemo = class()
    // ...
    FLines: TStrings;
    // ...
  end;

constructor TCustomMemo.Create(AOwner: TComponent);
begin
  // ...
  FLines := TMemoStrings.Create;
  // ...
end;

...

[Muetze1]

Asche über mein Haupt. Delphi 5 veröffentlicht die Eigenschaft des TMemo noch als TMemoStrings, ab D6 wird es als TStrings veröffentlicht. TMemoStrings sind natürlich von je her von TStrings abgeleitet. Die Instanziierung habe ich mir leider nicht mehr angeschaut. Also ich nehme alles zurück und behaupte das Gegenteil, bis auf den Beitrag von mir, auf den sich die Diskussion bezieht... :stupid: Ist das rechtlich so eindeutig?

[marabu]

Auf diese ausgefeilte Argumentation bin ich überhaupt nicht vorbereitet - ich werde meinen Rechtsbeistand befragen.

[DeddyH]

Findet Ihr nicht, dass dieser Thread für die eigentliche (recht simple) Aufgabenstellung nun genug aufgebläht ist? :mrgreen:

[peschai]

.... war trotzdem interessant zu folgen ...