GUI-Ausgaben.

[Zet]

:autsch:Guten morgen miteinander, ich bins mal wieder.

Ich arbeite gerade an einem ASCII-Art generator, in dem aus einem eingegeben String wie:
String TextFuerAscii = "Hallo";



entsteht.

In der Konsole funktioniert das ganze soweit auch und wird korrekt angezeigt, wenn ich allerdings das ganze in einer grafischen Oberfläche(ScrollPane) anzeigen möchte, werden alle Zeichen in einer Zeile angezeigt.



ScrollPanel anlegen

log = new JTextArea();
log.setMargin(new Insets(5, 5, 5, 5));
log.setEditable(true);
JScrollPane logScrollPane = new JScrollPane(log);
logScrollPane.setBounds(25,50,xSize-300,ySize-100);

ASCII-ART erstellen

NameGenerator oGen = new NameGenerator(textFuerAscii);

JLabel erstellen mit der ASCII-ART

JLabel ausgabetext  = new JLabel(oGen.getAsciiText());

Einfügen des JLabels mit ASCII_Art an mein Scrollpanel

logScrollPane.setViewportView(ausgabetext);

Ich kann nicht nachvollziehen warum in einer JTextArea // ScrollPane der String in einer Zeile angezeiegt wird,
also # # # * # # * * # # * * # (so on...)
und in der Konsole korrekt.

Ist es die falsche Ausgabe-Komponente oder vergesse ich da etwas im Umgang mit den Strings? alá \n ?


ist wohl mal wieder zu früh (coffee)


grüße
Zet

 

[Joose]

Ich kann nicht nachvollziehen warum in einer JTextArea // ScrollPane der String in einer Zeile angezeiegt wird,
also # # # * # # * * # # * * # (so on...)
und in der Konsole korrekt.

Ist es die falsche Ausgabe-Komponente oder vergesse ich da etwas im Umgang mit den Strings? alá \n ?

Du schreibst zwar hier richtig von ein JTextArea welche Strings auch mehrzeilig anzeigen kann, verwendest im Code aber JLabel.

 

[Zet]

Morgen Joose,

danke dir erstmal,

ich war immer der Meinung man müsse um in einem ScrollPane einen text anzuzeigen

logScrollPane.setViewportView(ausgabetext);

verwenden. ein setText wäre natürlich toll
und dieser SetViewPortView-Methode muss man eine Komponente übergeben, ich dachte da waere JLabel die richtige Wahl gewesen, bin allerdings nicht sonderlich gut im Umgang mit GUI's.

sag mir nicht ich muss einfach der TextArea den String hinzufügen... moooment :idea:

Danke, ist schon ein wesentlich besseres resultat

aber immernoch leicht verzerrt,
Die Ausgabe der Console erfolgt eine Zeile bevor der TextArea die selble Variable hinzugefügt wird.

http://www.directupload.net/file/d/3589/hmcscrwd_png.htm


noch weitere Ideen was ich verunglümpft habe? :toll:

 

[Joose]

Schau mal nach wegen der Schriftart von der Textarea
Die meisten Konsolen (wenn nicht sogar alle) verwenden zur Anzeige Monospace Schriften.

 

[Zet]

:shock:In zwei Tagen erwischen mich zweimal die Schriftarten, ich packs nicht.


Vielen vielen Dank für die Lösung, ich wäre wiedermal nicht draufgekommen.

Grüße und einen guten Start ins Wochende!
Zet


/Edit:
Nun schreibt er alles korrekt, jedoch wenn die Area nicht groß genug ist, ignoriert er die restlichen Buchstaben der Eingabe die zur ASCII-Art werden sollen. (Auch kein Scrollbar sichtbar)
Füge ich allerdings ein paar Buchstaben per Hand ein, blendet sich die Scrollbar ein und ich kann zumindest per Hand weiteres einfügen

 

[Zet]

ich nochmal,

inzwischen funktioniert alles so wie ich mir das vorstelle.
Ich habe eine GUI mit 2 Buttons, Generiere und WriteToFile und ausgabefelder.

1 GUI Klasse GUI (Anzeige)
1 Logik Klasse NameGenerator(Erstellt ein Objekt das aus einem übergebenen String der GUI-Klasse einen ASCII-Text erzeugt. )

Über ein ActionCommand frage ich ab welcher Button gedrückt wurde.

nun sehen meine "Listener" folgendermaßen aus:

ASCII Generieren:

@Override
	public void actionPerformed(ActionEvent evg) 
	{
		if (evg.getActionCommand().equals("bGenerate")) 
		{
				String textFuerAscii = eingabeFeld.getText();
				try 
				{
					log.setFont(new Font(Font.MONOSPACED,0,12));
					NameGenerator oGen = new NameGenerator(textFuerAscii);
					log.setText(oGen.getAsciiText());
					oGen.setAsciiText(oGen.getAsciiText());
					log.setEditable(true);
				} 
				catch (IOException e) 
				{
					e.printStackTrace();
				}
		}


if (evg.getActionCommand().equals("bToFile")) 
		{	
			String textFuerAscii = eingabeFeld.getText();
			try 
			{
				log.setFont(new Font(Font.MONOSPACED,0,12));
				NameGenerator oGen = new NameGenerator(textFuerAscii);
				oGen.setAsciiText(oGen.getAsciiText());
				oGen.writeAsciiToFile();
				log.setEditable(true);
			} 
			catch (IOException e) 
			{
				e.printStackTrace();
			}
		}

Wie man sieht, erstelle ich wiederrum beim Schreiben des ASCII textes ein neues Objekt, obwohl ich ja letztendlch nur das (eigentlich schonmal erstellte) String-Attribut das mein ASCII enthält zugreifen möchte. Das ist wohl kaum im sinne der OOP, und die an die Fehler die die im weiteren verlauf dadurch somit (grade bei größeren Anwendungen als dieses kleine Progrämmchen...) entstehen können/werden möchte ich erst garnicht denken. Ist wohl kaum Sinn hier immerwieder neue Objekte zu erzeugen, ich soll ja schließlich auf "altes" wieder zugreifen, oder?
--> Klick auf generate --> erzeugung eines Objektes und ausgabe seines textes
--> Klick auf toFile --> erzeugung eines Objektes und ausgabe seines textes --> Schreiben in ein file

sollte ja bei toFile eher
--> Zugriff auf das (bereits)erzeugte objekt --> schreiben in ein File von Objekt.Text
sein



In einer GUI klasse sollte man aber doch auch nicht anfangen wieder Logik zu implementieren?
Also im Konstruktor ein neues Objekt erzeugen ect.? Bin mal wieder überfordert.

Wie Handhabt man sowas?
Habe leider keine Stelle wo ich soetwas nachfragen könnte wie man an sowas rangeht, weshalb ich euch dauernd nerven muss :noe:

Mir kommt das ganze Konstrukt einfach falsch vor, und das möchte ich mir nicht gleich angewöhnen.
Kann auch gern mal den Kompletten Code anzeigen, falls das weiterhelfen würde.. :rtfm:

Hoffe jemand erbarmt sich .


Grüße
Zet

 

[Joose]

Also oft werden ActionListener als eigene Klasse implementiert. Ob für jeden Button einen eigenen oder einer für alles kommt auf die Größe/Komplexität der GUI an usw.

Die Klasse mit der "actionPerformed" Methode sollte ein Klassenattribut vom Type NameGenerator haben. Wenn du nun einen Namen generieren willst erzeugst du ein Objekt von diesem Typ. Danach kannst du beim Klick auf den 2.Button entweder das schon vorhande Objekt verwenden oder wenn diese nicht erstellt wurde (==null) einfach eines erzeugen.

 

[Zet]

Joose, ich bin dir zu dank verpflichtet.

ist immer Hart, wenn man sich soviele gedanken macht, und es dann doch durch eine kleinigkeit einfach realisierbar ist. Zwei Wörter Code die alles verändern -_-.

Sollte soetwas inzwischen besser wissen, was solls.

Also danke dir,

Zet

 

[Zet]

Juchei leute,

Also, das schreiben in die Text-Datei funktioniert immernoch nicht.
Auch mit richtiger Schrifteinstellung(mono) im Editor, kommt ein verzerrtes Bild, füge ich das ganze in Word ein und stelle wieder auf Mono, erhalte ich das gewünschte ergebnis, wie auch in dem JTextField. Aber keine chance im MS-Editor.



Ehrlichgesagt steh ich mal wieder auf dem Schlauch(evtl Unicode, an was liegts, ect pp), Es kann ja auch nicht sein das der Anwender später um sein Ascii aus einem File zu kopieren, erstmal die Schrift umstellen muss:/, weshalb ich als verzweiflungstat versucht habe mit hilfe verschiedener (Schreib)Varianten in die .txt zu schreiben.

auch alle mit ähnlichen Fehlschlägen.

Gibt es nicht eine möglichkeit unabhängig der Schriftart ect. etwas zu schreiben?
Oder andere Vorschläge wie ich da vorgehen sollte/könnte?

aktueller Stand sieht wie folgt aus:


Falls irgendwelcher Code benötigt wird, kein problem.
[EDIT]Vergessts, hab beim anhängen nur \n statt \r\n gemacht...
muss ich nurnoch die standardschrift irgendwie umbrechen das der Nutzer nicht seine Schriftart erst umstellen muss[/EDIT]


Grüße
Zet

 

[Joose]

Verwendest du ein JTextField oder eine JTextArea?
Hat enthält dein Text Zeilenumbrüche? (in normalen Windows txt Editor kann man diese deaktivieren bzw. aktivieren)

Generell gilt: Den Text den du in die Datei schreibst ist einfach nur Text! Das was du siehst wenn du dir die Datei anschaust ist Editor abhängig. (welche Standardschrift, -art, -farbe, -größe halt eingestellt ist).

Es gibt aber Textdatei Formate die eben noch Formtierungs"daten" abspeichern (.doc, .docx, .rtf)

 

[Zet]

Huhu Joose,

sorry für die späte Meldung.
Ich nutze eine JTextArea in einer JScrollPane.

Konnte deinen Tipp umsetzen, schreiben in die Dateien funktioniert :toll: (solang es kein docx sein muss....)

Nun war ich dabei eine Menubar zu erstellen, in der man die Schriftgroesse ändern kann.
Problem: Der Algorithmus um das Raster in der der Text geschrieben wird festzulegen funktioniert nichtmehr. Gut, er war bisher sowieso grob, ein bisschen Luft hatte man immer.

Kannst du mir sagen wie sich die Proportionen, bzw Pixel-verhältnisse änern wenn ich beispielsweiße von Schriftgroesse 12 auf 13 springe? und sind diese änderungen Linear?

Problematisch sind eben eingaben, wo von Standard 12 auf 50 oder Höher gesprungen wird.
Dann wird der ASCII nur teilweiße angezeigt, da das Raster zu groß ist.

Multipliziere ich einfach die aktuelle Rastergröße mit dem Unterschied der Schriftgrößen, wird es wieder ein extrem großes raster, und die maschine rechnet ein "paar" Sekunden rum. NoGo.


Muss sich anfühlen als müsstest du all meine Probleme lösen


Gruß
Zet

 

[Joose]

Warum willst du die Schriftgröße variable machen?
Gib eine Schriftgröße fix vor und fertig.

Keine Ahnung wie diese Verhältnisse sind, sowas habe ich noch nie gebraucht