# Inhalt von StringBuffer löschen



## Brain (29. Mai 2006)

Hallo!!!
Weiß jemand wie man den Inahlt von einem StringBuffer löscht?

OK, da gibt es die Methode delete(int start, int end). Die setzt aber nur count auf 0, der eigentliche Inhalt bleibt erhalten.
Wenn ich mir das im Debugger anschaue, sieht das so aus:


```
--stringBuffer = StringBuffer (id=47)
  |--count=0
  |--value=char[16] (id=195)
    |--[0]=5
    |--[1]=6
    |--[2]=7
    |--[3]=8
    |--[4]=
    |--[5]=
    |--[6]=
    ....
    |--[15]=
```

So, und diese Werte muss ich löschen, denn wenn ich beim nächsten Mal Werte einfüge und es sind nur drei Werte, dann wird der Index 0 bis 2 überschrieben und die 8 (Index 3) bleibt erhalten.

Falls es was hilft, die delete()-Methode steht bei mir in einer for-Schleife.

Danke schon mal.


----------



## norman (29. Mai 2006)

```
deinAlterStringBuffer = new StringBuffer()
```


----------



## thE_29 (29. Mai 2006)

setLength(0); vielleicht?

Probier das mal aus!


----------



## Brain (29. Mai 2006)

Zur Antwort von norman:
Es funktioniert, der Inhalt von stringBuffer (so heißt mein StringBuffer) wird gelöscht, allerdings bekommt er auch eine neue ID. Wird damit nicht ein neues Objekt erstellt? Ist das OK?
Denn später, wenn das Programm fertig ist, muss unter Umständen hundert Mal ein neues Objekt erstellt werden. Oder wird dabei kein neues Objekt erstellt?

Der Vorschlag von thE_29 funktioniert leider nicht, da wird auch der count nur auf 0 gesetzt.


----------



## lhein (29. Mai 2006)

Die Antwort von thE_29 ist schon korrekt, wie ein Blick auf die API - Doku verrät.



> public void setLength(int newLength)
> 
> Sets the length of this String buffer. This string buffer is altered to represent a new character sequence whose length is specified by the argument. For every nonnegative index k less than newLength, the character at index k in the new character sequence is the same as the character at index k in the old sequence if k is less than the length of the old character sequence; otherwise, it is the null character '\u0000'. In other words, if the newLength argument is less than the current length of the string buffer, the string buffer is truncated to contain exactly the number of characters given by the newLength argument.



Ein setLength(0) bewirkt also, dass der Buffer bei 0 abgeschnitten wird.

Von einem 100fachen Instantiieren von StringBuffer - Objekten kann man wirklich nur abraten. (norman's Vorschlag)

LR


----------



## Brain (29. Mai 2006)

Irgendwie will es nicht funkionieren. Die setLength()-Methode hilft mir leider nicht weiter. Der Inhalt bleibt trotzdem erhalten.

Mache ich was falsch?

```
StringBuffer stringBuffer;

for (int i = 0; i < jTextField.length(); i++) {
  stringBuffer.delete(0, stringBuffer.length());
  stringBuffer.append("123");
  stringBuffer.delete(0, stringBuffer.length());
  stringBuffer.append("456");
}
```

Gibt es noch andere Möglichkeiten, den Inhalt von stringBuffer zu löschen?


----------



## lhein (29. Mai 2006)

Brain hat gesagt.:
			
		

> Irgendwie will es nicht funkionieren. Die setLength()-Methode hilft mir leider nicht weiter. Der Inhalt bleibt trotzdem erhalten.
> 
> Mache ich was falsch?
> 
> ...




Kannst Du mal erklären, was der Sinn dieses Codes sein soll ? Sieht irgendwie "sinnfrei" aus.
Denke sonst wirds schwer Dir hier zu helfen. Am besten mal beschreiben, was Du überhaupt machen
willst. Und vor allem was obiger Code eigentlich bewirken soll.

lr


----------



## Brain (29. Mai 2006)

Also, die for-Schleife ist nicht ganz. Ich habe sie zugeschnitten, da sie sonst sehr groß ist. Ich wollte eigentlich nur zeigen, was ich mit StringBuffer mache.

Der Sinn dieses Codes ist es den Inhalt des JTextFields zu selektieren.


----------



## lhein (29. Mai 2006)

Den Inhalt des Textfields zu selektieren? 

Also quasi:


```
jTextField.selectAll();
```

???

Bisl genauer brauchts das schon. Weil wenn das der Sinn der for-Schleife ist, dann beiss ich in die Tischkante.

lr


----------



## Brain (29. Mai 2006)

Nein, die Möbel kannst du in Ruhe lassen, - ich meinte damit, den String im JTextField zu zerteilen, so wie es StringTokenizer, Split oder Scanner macht. Bloß brauche ich nicht nur die Tokens sondern auch die Delimiter.

Deshalb wollte ich die Tokens und Delimiter einzeln nacheinander in einen StringBuffer schreiben und sie auch einzeln und nacheinander in eine ArrayList einfügen.


----------



## norman (29. Mai 2006)

Brain hat gesagt.:
			
		

> Irgendwie will es nicht funkionieren. Die setLength()-Methode hilft mir leider nicht weiter. Der Inhalt bleibt trotzdem erhalten.
> 
> Mache ich was falsch?
> 
> ...


ich sehe hier nirgends ein setLength()

soweit ich das sehe könntest du 

  stringBuffer.delete(0, stringBuffer.length());

mit

  stringBuffer.setLength(0);

ersetzen.


----------



## Brain (29. Mai 2006)

Klar, das habe ich auch gemacht. Aber wie gesagt, leider funktioniert das setLenght() genauso wenig wie delete().

Das war zum Teil mein Originalcode.

Gibt es Möglichkeiten beim Zerschneiden von Strings die Delimiter auch mitzuschneiden? Die Delimiter dürfen nicht verworfen werden.


----------



## norman (29. Mai 2006)

Brain hat gesagt.:
			
		

> Gibt es Möglichkeiten beim Zerschneiden von Strings die Delimiter auch mitzuschneiden? Die Delimiter dürfen nicht verworfen werden.



du kannst dem StringTokenizer so erstellen, dass er die delims nicht verwirft:

StringTokenizer(String str, String delim, boolean returnDelims)


----------



## Brain (29. Mai 2006)

OK. Habe ich übersehen. Danke.

Noch 'ne Frage: Sollte man StringTokenizer noch verwenden?

split() oder Scanner bieten keine Parameter oder Methoden an wie StringTokenizer, um die Delimiter zu behalten.

Außerdem, was mir an StringTokenizer auch nicht gefällt, ist, dass die Delimiter nur einzelne Zeichen sind.


----------



## Leroy42 (29. Mai 2006)

Nochmal zu deiner ersten Frage:



			
				Brain hat gesagt.:
			
		

> Der Vorschlag von thE_29 funktioniert leider nicht, da wird auch der count nur auf 0 gesetzt.



Und damit besitzt der StringBuffer _nach außen_ auch einen _leeren String_.

Das die interne, und nur durch den Debugger zu _sehende_, Repräsentation noch
die Zeichen hat, ist doch vollkommen egal. Aus Anwendersicht handelt es sich eben
um einen Leerstring. 

Zum Beispiel kopiert die substring-Methode auch keine einziges Zeichen, sie liefert
nur einen neuen String_Container_, der einen eigenen startindex und eine eigene
Länge besitzt; aber auf _dasselbe_ Zeichenarray wie der Originalstring verweist.

Durch die Unveränderlichkeit von Strings ist dies auch erlaubt und sinnvoll. Wird z.B.
der Originalstring nicht mehr gebraucht, also keine Referenz mehr auf ihn besteht,
wird er vom GC zwar entsorgt, da der neue (mittels substring gebildete) String aber
nachwievor auf das Zeichenfeld des Originalstrings zeigt, wird _nur dieses_ Zeichenfeld
vom GC verschont.


----------

