# SWT: Button mit Text und Image



## Reinhard (10. Apr 2006)

Hallo,

ich wollte mit Eclipse 3.1.2 und SWT einen Button erstellen, der einen Text hat und gleichzeitig ein Image anzeigt.
Ich kann hier kein Bild hochladen, sonst hätte ich euch besser beschreiben können was ich meine.

Ich möchte einen Button z.B. auf dem "Abbrechen" steht und gleichzeitig z.B. "ein rotes x" dargestellt wird (ich hoffe es ist klar was ich meine).

Ich habe es so versucht:


```
btnOK.setImage(SWTResourceManager.getImage(Login.class, "/img/datei_5loeschen.png"));
    btnOK.setText("OK");
```

Aber entweder es wird das Image oder der Text dargestellt.
Ist es evtl. ein Problem das ich das ganze mit SWT-Designer erstellen wollte / erstellt habe?

Kann mir dabei jemand weiterhelfen?

Danke,
Reinhard


----------



## ronny (10. Apr 2006)

Hallo,

tjoa, das gibts leider nicht in SWT... 
Da müsstest du schon selbst ein Widget basteln, was aber ziemlich mühsam werden kann...   

Mit den GUI-Designern hat das nix zu tun..


----------



## Reinhard (11. Apr 2006)

Hallo ronny,

vielen Dank für die Antwort. Hab dazu leider nirgends eine Info gefunden.
Ein extra Widget zu basteln rentiert sich dafür denk ich mal nicht. 

Schöne Grüße,
Reinhard


----------



## byte (11. Apr 2006)

Falls der Text nicht dynamisch erzeugt wird, wäre eine einfache Lösung folgende: Du nimmst den Text einfach mit ins Bild auf, indem Du das Bild geeignet mit einer Bildbearbeitungssoftware editierst. Ansonsten klappt es vielleicht, dem Button ein Label zuzuweisen und Bild +  Text auf dem Label zu platzieren. Da bin ich mir jedoch nicht sicher, da ich es selbst noch nie probiert habe.


----------



## Reinhard (11. Apr 2006)

@byto:
Die Buttons und den Text als Bild erstellen, ist wahrscheinlich für die Anzahl der Buttons zu aufwändig.
Wie kann ich denn einem Button ein Label zuweisen?

Schade das das ganze in Swingt mit setIcon auf den Button funktioniert hat


----------



## byte (11. Apr 2006)

Hm ok, ich sehe grade, das mit dem Label geht gar nicht mehr. Schade.


----------



## Reinhard (11. Apr 2006)

Hm, langsam stellt sich bei mir die Frage, ob SWT für eine reine Windows-Anwendung in Java der richtige Weg ist.
Was meinst ihr dazu?

Der Standard ist ja weiterhin Swing, oder?


----------



## SammY (11. Apr 2006)

Also ich verwende schon die Swing.
Bin bis jetzt sehr gut damit gefahren und kann es nur weiterempfehlen.

Gruß Manuel


----------



## ronny (11. Apr 2006)

das Problem ist, dass viele NUR SWT betrachten...
Aber eigentlich spielt das erst in der Kombi mit jface und RCP zusammen..
Damit ist eine meiner Meinung nach sehr gute Plattform entstanden, 
mit der man gute rich-clients programmieren kann. 

Ich hab mittlerweile ein komplettes CRM System mit RCP mitentwickelt
und auch komplexere eclipse-plugins entwickelt... Früher selbst mit
Swing gearbeitet, aber irgendwie bin ich komischerweise
von RCP mehr überzeugt und auch da hängengeblieben... 

aber das ist wohl reine Ansichtssache und je nach Bedarf zu beurteilen...
Nichtsdestotrotz, um gleich mal die Grundsatzdiskussion SWT vs. Swing
im Keim zu ersticken, bleibt Swing in Sachen GUI-Programmierung / Stil
State of the Art... 

Man sollte dennoch SWT mit jface und RCP eine Chance geben...  :wink:


----------



## paedubucher (11. Apr 2006)

Um die Diskussion weiterzuführen... ;-)

SWT und Swing sind vom Anstatz her etwas anders zu programmieren. Swing stellt für mich eher ein durchgehend sauberes OOP-Design dar, während SWT teilweise auf "Hacks" zurückgreift (die Art und Weise, wie man mehrere Layout-Konstanten im Konstruktor übergibt oder sich ein Button erst bei der Instanzierung entscheidet, ob er ein Radio-Button oder eine Checkbox werden soll).

Wenn du ein Windows Look & Feel möchtest, so kannst du ab Herbst (Java Mustang) auch problemlos Swing verwenden. Die Komponenten werden nun von Windows (bzw. Wirtsbetriebssystem) gerendert und sehen somit absolut identisch aus wie Komponenten, die du mit SWT erzeugst.

Das pro-SWT-Argument, dass SWT sich perfekt an das Wirtssystem anpasst und Swing nicht, hinkt. SWT erfindet z.B. eine Koponente Namens CTabFolder, welche sich eindeutig von "normalen" Tabs unterscheidet. Aber ich finde, es gibt keine echten Killer-Kriterien, an welchen einer der beiden Toolkits scheitern würde. Beides erstklassige GUI-Toolkits mit einer Menge an Widgets/Komponenten. Zudem setzen bei der Gestaltung beide auf LayoutManager.


----------



## byte (12. Apr 2006)

paedubucher hat gesagt.:
			
		

> SWT und Swing sind vom Anstatz her etwas anders zu programmieren. Swing stellt für mich eher ein durchgehend sauberes OOP-Design dar, während SWT teilweise auf "Hacks" zurückgreift (die Art und Weise, wie man mehrere Layout-Konstanten im Konstruktor übergibt oder sich ein Button erst bei der Instanzierung entscheidet, ob er ein Radio-Button oder eine Checkbox werden soll).



Hä? Was ist daran bitte ein Hack? Das ist ne legitime Art, ner Methode "beliebig" viele Konstanten zu übergeben. Du hast insofern recht, dass die ganze Sache mit den int Konstanten nicht typsicher ist, aber das liegt ja nun an Java und dafür gibts ja heute die echten typsicheren Enums. Und was nun daran schlimm sein soll, dass es nur eine Button-Klasse für alle Buttons gibt, sehe ich jetzt auch nicht so. Vor allem sehe ich nicht, was daran unsauberes Design sein soll...



> Wenn du ein Windows Look & Feel möchtest, so kannst du ab Herbst (Java Mustang) auch problemlos Swing verwenden. Die Komponenten werden nun von Windows (bzw. Wirtsbetriebssystem) gerendert und sehen somit absolut identisch aus wie Komponenten, die du mit SWT erzeugst.



Was für SWT spricht, denn offensichtlich hat Sun erkannt, was (ein Großteil) der Nutzer wollen...



> Das pro-SWT-Argument, dass SWT sich perfekt an das Wirtssystem anpasst und Swing nicht, hinkt. SWT erfindet z.B. eine Koponente Namens CTabFolder, welche sich eindeutig von "normalen" Tabs unterscheidet.



SWT ermöglicht die Nutzung des nativen Fenstersystems. Da hinkt eigentlich gar nix. SWT erzeugt nur dann eigene Komponenten, wenn die Komponente nativ nicht verfügbar ist. Aber um mal auf Dein Beispiel zurückzukommen:

CTabFolder ist in der Tat eine Custom Komponente, aus dem Grund weil sie zusätzliche Funktionalität gegenüber der nativen Komponente bereitstellt. Alternativ kannst Du aber auch jederzeit TabFolder benutzen, den Wrapper für die echte native Komponente. Also das einzige was hier hinkt, sind Deine Argumente.


----------

