Steuerzeichen - Rechteck in Strings

[Tyler]

Hallöle,

ihr kennt ja sicherlich dieses komische Steuerzeichen, was in den String's z.B. Zeilenumbruch o.ä. darstellt.

Bei mir erscheinen die in einer Listbox z.B. als kleines gefülltest Rechteck innerhalb von SQL-Strings, die ich z.B. folgendermaßen zusammensetze:

Delphi-Quellcode:

  Query.SQL.Text := 'SELECT ';

  for i := 0 to Listbox.Count - 1 do
  begin
    if Listbox.Checked[i] = cbChecked then
      Query.SQL.Add( Listbox.Items.Strings[i] );
    if i < Listbox.Count - 1 then
      if (Listbox.Checked[i + 1] = cbChecked) AND
         (Listbox.Checked[i] = cbChecked) then
        Query.SQL.Add(', ');
  end;

Das problem tritt halt nicht nur in der Listbox auf, sondern auch in anderen Kompo's, z.B. MemoBoxen. Da nur ist es ein normales, ungefülltes Quadrat.

Tja, jedenfalls möcht ich das jetzt weghaben, weil das nicht unbedingt schön aussieht, nur weiss ich goarnicht wo's herkommt, oder wie das genau genannt wird.

Jemand ne Idee?


Danke
tyler

[Muetze1]

Moin!

Query.SQL ist eine Property des Typs TStrings und da du dort die Strings alle in eine eigene Zeile einfügst mit Add, werden diese einzelnen mit einem CR/LF verbunden, wenn du mit Query.SQL.Text dir den Inhalt rausholst. Wenn du nun aber diese auch einfach der ListBox.Items.Text zuweist, dann solltest du diese Zeichen nicht mehr sehen und statt dessen deinen Query genauso zeilenweise aufgedröselt wie du ihn erstellst in der Schleife.

Ansonsten wüsste ich nicht, woher diese Kästchen kommen sollten.

MfG
Muetze1

[Tyler]

Hallo!

Danke für deine Antwort erstmal. Ich versteh soweit was du meinst: Das Problem ist, ich muss versuchen das "Sql.Add" zu umgehen. Nur taucht dieses Steuerzeichen wohl bei allen SQL-Strings auf, auch wenn ich nur ein Simples "SQL.Text := 'SELECT * FROM table" an meine Memo etc übergebe, gibt es dieses Steuerzeichen.

Gut, die einzige Lösung wär halt für mich, den String einfach um ein Zeichen kürzen, das wäre ja dann das Steuerzeichen. Das ist nur sehr aufwendig wenn ich an meine FOR-TO-Schleifen mit dem SQL.Add denke.


tyler

[Muetze1]

Moin!

Zitat:

Zitat von Tyler

Danke für deine Antwort erstmal. Ich versteh soweit was du meinst: Das Problem ist, ich muss versuchen das "Sql.Add" zu umgehen. Nur taucht dieses Steuerzeichen wohl bei allen SQL-Strings auf, auch wenn ich nur ein Simples "SQL.Text := 'SELECT * FROM table" an meine Memo etc übergebe, gibt es dieses Steuerzeichen.

Gut, die einzige Lösung wär halt für mich, den String einfach um ein Zeichen kürzen, das wäre ja dann das Steuerzeichen. Das ist nur sehr aufwendig wenn ich an meine FOR-TO-Schleifen mit dem SQL.Add denke.

Why?

1.

Delphi-Quellcode:

Memo1.Lines.Text := Query1.SQL.Text

2.

Delphi-Quellcode:

Memo1.Lines := Query1.SQL;

3.

Delphi-Quellcode:

Memo1.Lines.Assign(Query1.SQL);

Such dir eine von den 3 Möglichkeiten aus und nutze sie - es gibt keine komischen Zeichen...

MfG
Muetze1

[Tyler]

supi, funzt tatsächlich so wie du es sagst! Hab ich gestern Nacht wohl ein wenig auf dem Schlauch gestanden *g*

Danke!

tyler

[Tyler]

tja, da gibt es nur leider zwei Probleme:

Das 1.:
Die Steuerzeichen sind zwar weg, werden aber immer noch Interpretiert, und zwar als "Zeilenumbruch", dass heist in meiner Memo hab ich jetzt für jeden Durchgang der o.g. For-To-Schleife eine Zeile. Das ist natürlich nicht im Sinne des Erfinders ;)


Das 2.:
Mit den 3 von dir genannten Möglichkeiten, wird der _gesamte_ Inhalt meines Memo's mit dem Inhalt der Query überschrieben. Ich hab aber 6 Querys deren Text ich nacheinander in die Memo schreiben will. So geht das also auch nicht.


Nun hab ich wieder folgendes probiert:

Delphi-Quellcode:

procedure Tf_main.QueryBeforeOpen(DataSet: TDataSet);
begin
  Query.SQL.Text := StringReplace(Query.SQL.Text, #13#10, '', [rfReplaceAll]);
  Memo.Lines.Add( Query.SQL.Text );
end;

Leider läuft das auch nicht, da die Zeilenumbrüche immer noch angezeigt werden :(

Folgendes: □□ befindet sich immer noch am Ende der Zeile. Die Zeilenumbrüche zwischen den einzelnen Feldangaben, die aus dem "SQL.Add" (siehe meine FOR-To-Schleife oben) herrühren, sind aber weg.

Im Klartext:
mit StringReplace:
SELECT id, name, vorname, email, telefon, password, level FROM access.access □□


ohne StringReplace:
SELECT id □□, name □□, vorname □□, email □□, telefon □□, password □□, level □□ FROM access.access □□

[Muetze1]

Moin!

Zitat:

Zitat von Tyler

Das 1.:
Die Steuerzeichen sind zwar weg, werden aber immer noch Interpretiert, und zwar als "Zeilenumbruch", dass heist in meiner Memo hab ich jetzt für jeden Durchgang der o.g. For-To-Schleife eine Zeile. Das ist natürlich nicht im Sinne des Erfinders ;)

Wie ich dir oben schon geschrieben habe, kommt das daher, das du jeden Teil einzelnd mit Add() hinzufügst - und ein Add() bedeutet eine neue Zeile - und eine neue Zeile wird von einem Zeilenumbruch eingeleitet, sonst wäre es keine neue Zeile...

Wenn du das nicht haben willst, dann musst du das anders programmieren, z.B. so:

Delphi-Quellcode:

Var
  lQueryCmd : String;    // über einen lokalen String zusammen zu bauen geht schneller als ständig Query.SQL.Text zu nehmen...
Begin
  ...

  lQueryCmd := '';

  for i := 0 to Listbox.Count - 1 do
  Begin
    if Listbox.Checked[i] = cbChecked then
    Begin
      If ( Length(lQueryCmd) > 0 ) Then
        lQueryCmd := lQueryCmd + ', ';

      lQueryCmd := lQueryCmd + Listbox.Items.Strings[i]; 
    End;
  End;

  Query.SQL.Text := 'SELECT ' + lQueryCmd;

Zitat:

Zitat von Tyler

Das 2.:
Mit den 3 von dir genannten Möglichkeiten, wird der _gesamte_ Inhalt meines Memo's mit dem Inhalt der Query überschrieben. Ich hab aber 6 Querys deren Text ich nacheinander in die Memo schreiben will. So geht das also auch nicht.

Das wusste ich nicht und ich bin davon ausgegangen, das du den gesamten Query im Memo haben wolltest. Ansonsten nutze die Methode AddStrings()

Delphi-Quellcode:

Memo1.Lines.AddStrings(Query1.SQL);

Zitat:

Zitat von Tyler

Nun hab ich wieder folgendes probiert:

Delphi-Quellcode:

procedure Tf_main.QueryBeforeOpen(DataSet: TDataSet);
begin
  Query.SQL.Text := StringReplace(Query.SQL.Text, #13#10, '', [rfReplaceAll]);
  Memo.Lines.Add( Query.SQL.Text );
end;

Leider läuft das auch nicht, da die Zeilenumbrüche immer noch angezeigt werden :(

Was auch logisch ist. Ein von TStrings abgeleitetes Objekt hält intern nicht diesen grossen String sondern die einzelnen Zeilen. Immer wenn du auf die Eigenschaft Text lesend zugreifst, dann wird intern erstmal aus den einzelnen Zeilen mit dem Zeilenumbruch ein grosser String zusammen gebastelt. Wenn du einen String mit Zeilenumbruch der Text Eigenschaft zuweist, dann wird dieser an den Zeilenumbrüchen wieder auseinandergenommen und die einzelnen Zeilen werden zugewiesen. Daher hast du beim Memo.Lines.Add() wieder mindestens ein Zeilenumbruch drinne, da du auf .Text zugreifst.

MfG
Muetze1

[Tyler]

Wow, jetzt funktionierts wirklich. Ich benutze die Methode "AddStrings" und natürlich vorher die ReplaceString-Funktion.

Die SQL-Query erst in einem String zusammen zu setzen und dann an die Query zu geben, hatte ich mir auch schon überlegt, ich bin aber allgemein mit den Variabeln etwas geizig ^^

Danke für deine Geduld! :)

tyler

[Muetze1]

Moin!

Zitat:

Zitat von Tyler

Wow, jetzt funktionierts wirklich. Ich benutze die Methode "AddStrings" und natürlich vorher die ReplaceString-Funktion.

Das ist aber um längen langsamer als wenn du es gleich ordentlich in einer Variablen zusammen setzt und diese z.B. direkt an das Memo hängst.

Zitat:

Zitat von Tyler

Die SQL-Query erst in einem String zusammen zu setzen und dann an die Query zu geben, hatte ich mir auch schon überlegt, ich bin aber allgemein mit den Variabeln etwas geizig ^^

Warum? Ist a) eine lokale Variable und wird daher nach verlassen der Procedure eh in Staub zerfallen und b) ist sie doch nur in der Procedure gültig und nicht global. Und zu guter letzt noch c): Sie nimmt dir doch keinen Speicher weg, da er nach Verwendung des Strings eh wieder freigegeben wird.

Ich würde lieber nicht am falschen Ende sparen...

MfG
Muetze1

[Tyler]

okay, ich werd deinen Rat befolgen. Am Ende gewinnt der Quellcode ja auch noch an Übersichtlichkeit, ist also auf jedenfall der bessere Weg :)

ki