Package Struktur für GUI Programmierung

MiMa

Top Contributor
Ich habe bei der GUI Programmierung mit FXM. Kontroller und Auslagerungen von Methoden, das es ganz schnell unübersichtlich wird.
Daher wollte ich gerne wissen wie ihr eure Paket-Strukturen organisiert?
Für ein Border-Pane habe ich mir überlegt folgende Struktur zu verwenden!
GUIpackage.JPG
was haltet ihr davon?

Auch habe ich festgestellt, das ein MVC Modell komplett losgelöst von Kontroller einem den Kopf verdrehen kann.
Daher habe ich mir überlegt ob das komplette loslösen unbedingt sein muss?
Danke
Mi
 

dzim

Top Contributor
Also mal davon abgesehen, das ich die Trennung von Code und Ressourcen, zu der man mit Build-Tools wie Maven oder Gradle "gezwungen" wird, deutlich besser finde gibt es folgende (Kritik-)Punkte an der bestehenden Struktur:
  • es gibt anscheinend Daten im "default package", also im obersten Verzeichnis der Paketstruktur. Das ist ein No-Go, wenn das eine produktive Anwendung werden soll
  • package-Namen werden grundsätzlich klein geschrieben - und am besten auf English (daran muss man sich beim Coden gewöhnen!):
  • in Packages werden häufig gleichartige Codeblöcke eingefügt, also z.B. eine Package für Controller, eines für Services, eines für Utilities, etc.
    z.B. ein wenig hier beschrieben: https://dzone.com/articles/package-structure
Einfaches Beispiel, wie ich es machen würde:
Code:
eu.dzim.<my_program>
 \- Main / Launcher class of my application

eu.dzim.<my_program>.db
 \- classes used to interact with some database

eu.dzim.<my_program>.model
 \- model classes, I use throughout the application

eu.dzim.<my_program>.service
 \- my services (interaction with ReST-Services, calculating stuff, etc.)

eu.dzim.<my_program>.ui
 \- either UI controller, when I use FXMLs or UI classes, when I write the UI in code

eu.dzim.<my_program>.ui.controller
 \- optional
  - when I write the UI in code, I usually add it to the parent package
  - when this gets too large, I separate the controller into the sub-package 

eu.dzim.<my_program>.ui.utils
 \- optional
  - when I have utilites specific to UI, e.g. methods to create specific UI block
    change appearances, etc.

eu.dzim.<my_program>.utils
 \- application utilities, that are general purpose and to not fit into any
    specific class alone

eu.dzim.<my_program>.<topic-specific-package>
 \- what I mean by that is, that I create packages to a specific topic, if it either
    doesn't fit into another package or the package would be to large
  - e.g. in one tool I have "eu.dzim.<my_program>.model.util", because I needed specific utilities,
    or "eu.dzim.<my_program>.dialog", for a custom dialog API

Zum Thema MVC (oder gar MVVN): Ja, am Anfang fällt einem es etwas schwerer, aber langfristig profitierst du davon, denn du trennst eben die Darstellung vom unterliegenden Applikationsmodell und dem Verhalten. Klar kannst du alles (speziell UI un Controller) in einem Topf werfen, aber wenn du dann was anpassen musst, musst du dich jedes Mal durch alles durchwühlen, anstelle nur in den sauer getrennten Teilen zu suchen.
Tu dir einen Gefallen und werde nicht nachlässig. Egal ob du FXMLs verwendest (hier ist es ja relativ leicht, da einen das Prinzip ja dazu zwingt, UI und Controller zu trennen), oder deine GUI in Code schreibst, vermische es nie!
 

MiMa

Top Contributor
Vielen Dank für deine Antwort.
Die Package habe ich Groß geschrieben weil "Test Packages, Libraries und Test Libraries" auch groß geschrieben wurde und dachte das es allgemein so ist.
Ich werde das Package umstellen und alle gleichen Dateiarten zusammen packen.
Im "default package" ist nur eine Datei enthalten und zwar die log4j2.xml.
Ich werde deinen Rat annahmen und mehr Code trennen und dann auch den Controller und die onAction.
Ist für mich nach wie vor mit mit viel Gehinschmalz zu meistern, hoffe das es irgendwann besser wird.
Danke
Mi
 

White_Fox

Top Contributor
Vielleicht noch ein Vorschlag, was Packageaufteilung angeht:

view struktur.PNG

Alles, was view ist, landet im viewpaket. Oder in einem Unterpaket, wenn es sich mehreres zusammenfassen läßt. Ich hab keine Ahnung ob das eine gute Struktur ist, aber sie war mir bisher zumindest nicht hinderlich.
 

thecain

Top Contributor
mMn sollte die Packagestruktur die Architektur abbildern. Ich gruppiere dann gerne nach Feature um die Möglichkeit für einen Schnitt zu haben und versuche mich strikt an meine Layer zu halten. Dadurch kann ich an den Imports auch "einfach" prüfen ob ich meine Architektur eingehalten habe.

Wobei ich sagen muss, dass ich mehr im Enterprise Java Bereich unterweges bin und weniger in der GUI Entwicklung

Beispiel

Code:
- ch.thecain.shop
   - cart
     - model
     - view
     - controller
   - register
     - model
     ....

Util Klassen versuche ich zu vermeiden, da sie nicht in meinen Designansatz passen.
 

dzim

Top Contributor
Ich glaube am Ende findet jeder so seinen für sich "besten" Ansatz. Ich bin meist eher pragmatisch und verwende Utils für "unspezifisches" Zeug, das nur in einer Anwendung vorkommt. Ansonsten versuche ich schon eher generelle APIs und separate Pakete, die ich dann in meine Dependencies machen kann, draus zu erstellen.

Die Trennung in Features kommt bei mir nur dann vor, wenn sonst ein Packet durch zu viele verschiedene Dinge aufgebläht werden würde. Ist aber zugegeben eher selten. Finde den Ansatz aber auch voll OK (und eigentlich erstrebenswert, nun ja... 🤷‍♂️ Menschen sind Gewohnheitstiere).
 

MiMa

Top Contributor
Ja ich denke jeder wird seine Struktur finden, wenn man erstmal damit arbeitet.
Auf jeden Fall vielen Dank für die Einblicke.
 

White_Fox

Top Contributor
Hm...ich bin mir sicher das thecain gute Gründe für eine solche Packagestruktur hat. Aber ich kann mir schlecht vorstellen wie das vernünftig funktionieren soll.

Ich hab das so geregelt, daß alle Viewelemente (verschiedene Panes wie LibraryBrowserpane, die verschiedenen Kontextmenüs, Toolbar, usw.) zentral (über ein eigenes Interface) über die View-Klasse mit Model und Controller agieren. So gibt es z.B. eine Methode "saveLibraryAs", und innerhalb dieser Methode wird veranlaßt, den Benutzer nach einem neuen Pfad zu fragen und den Befehl dem Controller zu übergeben. Genauso fragt auch nicht jedes Viewelement beim Model separat Daten ab, sondern diese Interaktionen geschehen über dieselbe Schnittstelle.

Das habe ich gemacht, um in der Gestaltung der Benutzeroberfläche vom Model möglichst frei zu sein. Ich kann von beliebigen -- auch beliebig vielen -- Stellen aus beliebig Befehle ausführen.
Ganz perfekt ist es bei mir noch nicht - im Moment habe ich noch das Problem daß ich damit relativ viel Last produziere, weil teilweise die gleichen Daten mehrmals vom Model erstellt werden - aber das kann ich sehr gut anpassen da ich dazu lediglich in der Viewklasse etwas ändern muß.

Wie gesagt, thecain wird sicher gute Gründe für sein Design haben. Aber ich sehe nicht, daß das Vorteile bringt -- ich sehe erstmal schon rein vom Arbeiten her eine sehr dichte Entwicklung von GUI und Restprogramm. Genau das wollte ich z.B. vermeiden. Von daher wäre ich an weiteren Ausführungen interessiert.
 

mrBrown

Super-Moderator
Mitarbeiter
Hm...ich bin mir sicher das thecain gute Gründe für eine solche Packagestruktur hat. Aber ich kann mir schlecht vorstellen wie das vernünftig funktionieren soll.
Tatsächlich funktioniert das sogar ziemlich gut, solange man die Domäne sinnvoll unterteilt hat. Es kommt dem üblichen Entwicklungsansatz ganz gut entgegen, dass man an einem Kontext arbeitet (um bei @thecain's Beispiel zu bleiben: zb Verändert man nur die Registrierung), und darin mehrere Dinge anfasst (zB Name wird in Vorname & Nachname geteilt, man muss Model, View und Controller anpassen), aber selten Kontextübergreifend arbeitet (wenn man extra Vornamen einführt muss man zB den Warenkorb eher nicht anfassen).

Die Trennung in MVC hätte man weiterhin – nur halt gruppiert nach Feature. Wenn du natürlich nur im wesentlich ein Feature hast, entfällt die oberste Ebene bei der Struktur und man hätte direkt model, view & controller

Code:
- ch.thecain.shop
   - cart
     - model
     - view
     - controller
   - register
     - model
     ....
Code:
- ch.thecain.shop
   - model
     - cart
     - register
   - view
     - cart
     - register
   - controller
     ....
 

White_Fox

Top Contributor
Aber wird das nicht dann unübersichtlich, wenn man die gleiche Aktion an verschiedenen Punkten hat? Wenn man z.B. speichern will wenn man auf den Speichernknopf drückt, eine bestimmte Tastenkombination drückt und evt. z.B. vor dem Schließen des Programms?

Oder anders herum: Der angemeldete Benutzer wird irgendwo oben rechts angezeigt, aber auch z.B. in irgendwelchen Formularen, die mit dem Benutzer selber eigentlich gar nichts zu tun haben, außer daß sie ihn als Datum verwursten?
 

LimDul

Top Contributor
Das habe ich gemacht, um in der Gestaltung der Benutzeroberfläche vom Model möglichst frei zu sein. Ich kann von beliebigen -- auch beliebig vielen -- Stellen aus beliebig Befehle ausführen.
Ohne das jetzt für den Fall konkret zu bewerten. Pauschal kann das gefährlich sein. Den im Worst-Case hat man nun (egal ob man UI oder Befehle ändert) das Problem das man alles andere prüfen muss. Sprich, das kann zu einer engen Kopplung führen, die man eben vermeiden möchte.

Aber um es besser zu bewerten, muss man glaub ich mehr ins konkrete gehen - den "was ist ein feature", was ist das "Model", was ist der "Controller". Das wird schnell sehr diffiziell und Dogmatizmen sind da gefährlich (aber genauso es einfach beliebig zu machen weil es für den Fall besser sein soll)
 

White_Fox

Top Contributor
Hm...die Gefahr sehe ich in meiner Umsetzung überhaupt nicht. Ich will zwar nicht ausschließen daß ich mich ganz fatal irre, aber -- ich sehe die Gefahr nicht. @mihe7 hat in irgendeinem Nachbarthread eine schöne Prüfung erwähnt: Baue so, daß du ohne weiteres eine andere GUI drüberlegen könntest - sinngemäß jedenfalls.
Und ich denke, das könnte ich. Ich könnte z.B. ohne Weiteres eine Konsolenoberfläche drüberlegen. Das wäre zwar grausam unkomfortabel zu bedienen, aber meine Codestruktur gibt das ohne Weiteres her, ohne das ich Model oder Controller ändern müßte.

Die Viewelemente arbeiten auf einem Interface (ViewdataControllable), das von der View bereitgestellt wird und das die besagten Methoden enthält. Die Viewelemente werden von der Viewklasse instanziert, angeordnet und verwaltet (z.B. beim Model als Listener für bestimmte ModelChangeevents angemeldet, wobei allerdings jedes Viewelement selber sagt für welche ModelChangeevents es angemeldet werden will). Ansonsten sind die Viewelemente beliebig austauschbar, gerne auch mehrfach instanzierbar (auch wenn es eigentich Unsinn ist), und die Viewelemente können gegen ein beliebiges anderes Objekt arbeiten, solange es das ViewdataControllableinterface implementiert. Nur mit JavaFX-Objekten muß es umgehen können, da alle Viewelemente von irgendwelchen JavaFX-Klassen abgeleitet sind.


Ich muß allerdings zugeben, daß ich langsam vor einem anderen Problem stehe: Ich hatte ursprünglich mal eine monolothische Viewklasse, in der alles drin war. Die Codemenge ist aber so dermaßen schnell gewachsen (>100 Codezeilen nur für Imports), daß ich da sehr schnell den Überblick verloren habe, deswegen habe ich überhaupt angefangen das derart in Einzelteile zu zerreißen.
Aber mittlerweile kommen da so viele Methoden zusammen, daß ich wieder vor dem alten Problem mit dem vielen Code stehe. Das geht soweit daß ich sogar versehentlich einmal eine Methode doppelt geschrieben habe. Was allerdings auch daran liegt, daß ich das Viewgeraffel seit einem dreiviertel Jahr nicht mehr angesehen habe.
 

LimDul

Top Contributor
Ich muß allerdings zugeben, daß ich langsam vor einem anderen Problem stehe: Ich hatte ursprünglich mal eine monolothische Viewklasse, in der alles drin war. Die Codemenge ist aber so dermaßen schnell gewachsen (>100 Codezeilen nur für Imports), daß ich da sehr schnell den Überblick verloren habe, deswegen habe ich überhaupt angefangen das derart in Einzelteile zu zerreißen.
Aber mittlerweile kommen da so viele Methoden zusammen, daß ich wieder vor dem alten Problem mit dem vielen Code stehe. Das geht soweit daß ich sogar versehentlich einmal eine Methode doppelt geschrieben habe. Was allerdings auch daran liegt, daß ich das Viewgeraffel seit einem dreiviertel Jahr nicht mehr angesehen habe.
Naja, das spricht für fehlende Struktur :) Den eigentlich sollte klar sein, was jede Klasse macht und was da rein gehört (und zwar genau eine Aufgabe). Aber ich kenne das Problem aus meinen früheren Zeiten, man neigt dazu immer noch was dazu zu packen, anstelle konsequent neue Klassen und ggf. neue Packages zu machen.
 

mihe7

Top Contributor
@mihe7 hat in irgendeinem Nachbarthread eine schöne Prüfung erwähnt: Baue so, daß du ohne weiteres eine andere GUI drüberlegen könntest - sinngemäß jedenfalls.
Ja, das führt einfach zur Trennung von Logik und Darstellung. Das ist natürlich sehr grob und ist als erste Maßnahme für die meisten Probleme gedacht, die hier im Forum angetragen werden, um für überhaupt etwas Struktur zu sorgen.

Oder anders herum: Der angemeldete Benutzer wird irgendwo oben rechts angezeigt, aber auch z.B. in irgendwelchen Formularen, die mit dem Benutzer selber eigentlich gar nichts zu tun haben, außer daß sie ihn als Datum verwursten?
Da sehe ich keinen Widerspruch. Zum view-Paket des Benutzers könnte z. B. ein Formular zur Verwaltung des Profils zählen oder eine Komponente zum Zurücksetzen es Passworts. Das hindert nicht daran, dass das Benutzerobjekt an anderer Stelle verwendet wird.
 

White_Fox

Top Contributor
Ich meinte eher, daß es verdammt viele Methoden werden. Mit jeder neuen Funktion des Programms kommen meist mehrere neuen Methoden hinzu. Jede Klasse hat durchaus nur eine Aufgabe. Ich versuche das mal mit einer Metapher zu beschreiben:

Du machst einen Pizzaladen auf, und beschäftigst zum Ausliefern einen befahrradeten Pizzaboten. Anfangs ist das völlig ausreichen, hast kaum Kunden, der Pizzabote ist mehr mit Rauchen als mit Ausliefern beschäftigt. Dein Pizzaladen läuft immer besser, der arme Knecht hat immer mehr zu tun und muß irgendwann Überstunden machen. Nach und nach werden es immer mehr Kunden, die auch immer weiter weg wohnen, und irgendwann ist die Aufgabe "Liefere Pizza aus" für den Fahrradtreter einfach nicht mehr zu stemmen. Obwohl sich die Aufgabe im Prinzip nicht geändert hat, sie ist ja nichtmal komplizierter geworden - nur größer.

ABER: Gestern abend ist mir - kurz vorm Einschlafen - dank dieses Threads ein Einfall gekommen wie ich das Dilemma doch lösen kann. Nicht sonderlich elegant, aber zweckmäßig und mit sehr gut verständlichem Code, denke ich jedenfalls.

Von daher bedanke ich mich recht herzlich bei dir, @LimDul, für das Nachhaken und Hinterfragen. :)
Und bei @MiMa für diesen Thread.
 

temi

Top Contributor
Ich bin ja auch nur Hobbyprogrammierer und hätte da mal eine Frage:

Model - View - Controller

Die GUI hat ja u.U. andere Ansprüche an das Model als die Geschäftslogik. Ist es denkbar oder üblich, dass ich in einer Anwendung unterschiedliche Datenklassen habe für UI und Logik?

Ich hoffe ihr habt verstanden, was ich meine, ansonsten kann ich versuchen ein Beispiel auszudenken.
 
K

kneitzel

Gast
Ja, das ist möglich.

Einfach einmal paar Beispiele, die das etwas zeigen:
Spring MVC mit Thymeleaf: Model ist da eigentlich eine feste Klasse und man fügt da die Daten nur noch hinzu (als Attribute). Das sieht man z.B. bei https://www.baeldung.com/thymeleaf-in-spring-mvc

JavaFX: wenn man hier ein Binding haben will, dann kommt man auch um eigene Klassen nicht herum, denn dann will man ja z.B. Statt String eine StringProperty habe. (Ein Grund, warum mir mvvmFX besser gefällt - das MVC ist nicht wirklich überzeugend in JavaFX. Aber wichtiger ist, dass die Trennung von Controller und View halbherzig ist... Das führt hier aber zu weit)

Das einfach nur als kleine Beispiele, die aufzeigen, dass ein Model keine Entity Klasse oder so sein muss.
 

White_Fox

Top Contributor
Die GUI hat ja u.U. andere Ansprüche an das Model als die Geschäftslogik. Ist es denkbar oder üblich, dass ich in einer Anwendung unterschiedliche Datenklassen habe für UI und Logik?
Nun, soweit ich das bisher sehe: Denkbar ist es auf jeden Fall, und zumindest ich mache das auch so.

Bei mir haben GUI und Controller separate Interfaces, über die sie auf das Model zugreifen. Während der Controller direkt auf dem Model arbeiten kann, bekommt die GUI nicht die Ergebnisse direkt, sondern ein paar Datencontainerobjekte.
Ich habe z.B. im Model eine Baumstruktur. Dieser Baum kann ein Modell seiner selbst erstellen, wobei jedes Baumelement ein Objekt vom Typ TreeitemModel exportiert. Ein TreeitemModel-Objekt enthält Informationen darüber, wie das zugehörige TreeItem addressiert wird, es enthält alle TreeitemModel-Objekte der TreeItems, die das zugehörige TreeItem auch enthält sowie natürlich Informationen über das TreeItem selbst, wie z.B. sein Name.
 

mrBrown

Super-Moderator
Mitarbeiter
Die GUI hat ja u.U. andere Ansprüche an das Model als die Geschäftslogik. Ist es denkbar oder üblich, dass ich in einer Anwendung unterschiedliche Datenklassen habe für UI und Logik?
In ganz klassischem MVC und auf die gesamte Applikation bezogen ist das Model die Geschäftslogik, und nicht nur einzelne "dumme" Datenklassen.

In kleinere Maßstab und je nach Architektur ist das Model auch primitiver, zB in dem von @kneitzel genannten Beispiel mit Thymeleaf.


Der Controller gehört doch auch zur UI, oder nicht?
Bei Controller von MVC, Nein. In JavaFX könnte man das denken, da der Code von FXML in einem Controller steckt. In diesem Fall ist der Controller aber Teil der View von MVC.
In klassischem MVC bilden V+C zusammen das User-Interface, V ist alles sichtbare, C alles was der Nutzer machen kann.
 
K

kneitzel

Gast
Dann habe ich es eh nie richtig angewendet und macht das ganze aber auch nicht attraktiver für mich. 🙃
Da würde mich interessieren, was Du anders (falsch?) gemacht hast?

Die Problematik bei JavaFX ist aus meiner Sicht, dass es da nicht wirklich sauber trennbar ist. Da muss der Controller gewisse "aktive" Parts mit übernehmen bzw. Wissen über den internen Aufbau der View bekommen, obwohl er das eigentlich nicht möchte. Und das Model, das eigentlich nur die Geschäftslogik sein soll und nichts Oberflächen-typisches haben soll, dem wird dann UI typisches aufgezwungen (Also die Verwendung von Property Klassen und so)....

Bei dem M V VM (Model View ViewModel) hat man das dann wieder etwas sauberer, denn dann hat man das eigentliche Model (Also die Business Dinge ohne jegliche JavaFX Dinge...) die View (die dann aus fxml und controller besteht) sowie dem ViewModel, das als Layer zwischen Model und View dient und so das Binding ermöglicht. (Bei mvvmFX dann z.B. mit Nutzen von Klassen aus dem Package de.saxsys.mvvmfx.utils.mapping).
@mrBrown Oder liege ich hier auch noch einem Missverständnis auf was mvc bei JavaFX angeht?

MVC sinnvoll eingesetzt habe ich in dem Sinne eigentlich nur im Web Bereich:
- Die Controller bieten nach außen die Schnittstelle an (Also mit Annotations wie z.B. @RequestMapping, die einem Path / Method etwas zuweisen und dabei gewisse Dinge erwarten - also Parameter vorgeben, die dann im Path oder Request vorhanden sein müssen)
- Model ist dann einfach eine Art Vertrag, welche Daten der Controller an die View zu übergeben hat.
- Die View nutzt die Daten vom Model um diese anzuzeigen und damit etwas zu machen und kann dann auf die bereitgestellte Schnittstellen der Controller zugreifen.
Geht im Web sehr schön, denn da habe ich nicht plötzlich eine Instanz vom Controller auf die ich relativ beschränkt bin. Ich kann auch beliebige Controller zugreifen, da ich halt beim Web die Requests habe. Da interessiert mich nicht wirklich, welcher Controller das genau macht. Also wenn ich dann ein request an some/path/someEntity/someId mit Post Abgebe, ist der genaue Controller egal. Die View kennt keinen konkreten Controller sondern lediglich die Info, dass die Applikation da einen Post Request annehmen kann. Das eine sehr schöne Trennung ist, denn genau das möchte ich ja haben! Ich will die Implementierungsdetails von Controller, View und Model möglichst frei und unabhängig voneinander ändern können. Und wenn der Controller dann die Controls der View kennt, dann ist das meiner Meinung nach kontraproduktiv.

Das ist so meine Sicht darauf...
 

sascha-sphw

Top Contributor
Ich habe gerade nochmal alten Code ausgegraben. Das hat mich jetzt zu sehr beschäftigt.
Wenn ich mir das Projekt so ansehe muss ich sagen, dass es mehr Ähnlichkeiten mit MVVM als mit MVC hat, damals kannte ich MVVM aber noch nicht, würde aber erklären warum ich mit MVC nicht klar gekommen bin. 😂

Bitte entschuldigt die Verwirrung. 😇
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
H JavaFX Fehlende JavaFX Package AWT, Swing, JavaFX & SWT 10
M error: package javafx.scene.web is not visible import javafx.scene.web.*; AWT, Swing, JavaFX & SWT 16
J Choicebox Helperclass in seperaten Package AWT, Swing, JavaFX & SWT 2
M JavaFX fx:include von anderem Package AWT, Swing, JavaFX & SWT 2
B Problem mit Bildpfad im Package AWT, Swing, JavaFX & SWT 3
S String an eine andere Klasse im anderem package übergeben AWT, Swing, JavaFX & SWT 3
P package com.javatutor.insel.ui.*; AWT, Swing, JavaFX & SWT 2
K welches package muss ich angeben um GUIs zu erstellen? AWT, Swing, JavaFX & SWT 5
S package javax.media does not exist AWT, Swing, JavaFX & SWT 5
S Eigenes Package für die GUI? AWT, Swing, JavaFX & SWT 6
G Excel-Zugriff über POI: wohin mit dem Package? AWT, Swing, JavaFX & SWT 4
T javax.swing - Package AWT, Swing, JavaFX & SWT 3
K Swing Struktur für TreeTable rekursiv aufbauen AWT, Swing, JavaFX & SWT 17
agent47 JavaFX TreeView Struktur dynamisch einlesen AWT, Swing, JavaFX & SWT 1
Tom299 JavaFX Projekt-Struktur AWT, Swing, JavaFX & SWT 2
J Swing Organisation & Struktur, die 2. AWT, Swing, JavaFX & SWT 4
J Swing MVC mit Java Swing, insbesondere die Controller-Struktur AWT, Swing, JavaFX & SWT 4
B Dialog aus DB Struktur erstellen AWT, Swing, JavaFX & SWT 4
H Struktur für Gui-Programmierung AWT, Swing, JavaFX & SWT 2
L Swing struktur und nahester Punkt AWT, Swing, JavaFX & SWT 4
M Abhängige JTable - MCV - Frage zu Struktur AWT, Swing, JavaFX & SWT 5
R Tree-Struktur in einer DB abspeichern AWT, Swing, JavaFX & SWT 15
Juelin Für Java-Spezialisten AWT, Swing, JavaFX & SWT 4
H JTabel - RowFilter Daten für Berechnung filtern AWT, Swing, JavaFX & SWT 6
I JavaFX JavaFx-Anwendung für die Erstellung einer Windows-Anwendung? AWT, Swing, JavaFX & SWT 6
M Eigene Java Klasse für allgemeine Grafikelemente AWT, Swing, JavaFX & SWT 8
M Vokabelprogram - Schleife für Liste soll schrittweise durchlaufen werden AWT, Swing, JavaFX & SWT 3
tommybalbor JavaFx Anwendung klappt nicht für macOs Nutzern, wenn ich zwei dependecies bei maven hinzufüge AWT, Swing, JavaFX & SWT 6
I Libraries für AWT für andere Grafik-Frameworks tauglich machen AWT, Swing, JavaFX & SWT 6
R auto. Importanweisungen für javafx funktioniert in Eclipse nicht mehr AWT, Swing, JavaFX & SWT 4
komplettlost Vollbildmodus für MacOs Nutzer geht nicht AWT, Swing, JavaFX & SWT 13
D JavaFX Schadensberechnung für Kartenspiel AWT, Swing, JavaFX & SWT 1
P JTable Listener für die Änderung einzelner Zellen oder Rows AWT, Swing, JavaFX & SWT 2
Jose05 JavaFX: eigene FXML-Datei für einen Button AWT, Swing, JavaFX & SWT 3
L actionListener für Button AWT, Swing, JavaFX & SWT 97
izoards Textfeld für Zeit AWT, Swing, JavaFX & SWT 4
CptK Wie funktioniert contains() für Path2D.Double AWT, Swing, JavaFX & SWT 10
T Getter und Setter für eine Stage AWT, Swing, JavaFX & SWT 6
P Swing Programm hängt sich bei Buttondruck auf? (GUI für "Chatbot" erstellen) AWT, Swing, JavaFX & SWT 15
T Button für GUI programmieren AWT, Swing, JavaFX & SWT 1
Z Switch Case für Buttons AWT, Swing, JavaFX & SWT 8
M Hough-Transformation für Kreise und andere Formen AWT, Swing, JavaFX & SWT 3
kodela HTML-tags für JLabel AWT, Swing, JavaFX & SWT 9
E Keystroke für Ausschneiden läßt sich nicht ändern AWT, Swing, JavaFX & SWT 2
M Swing Cell Renderer für Zeilenumbruch in JTable AWT, Swing, JavaFX & SWT 0
N JavaFX 1 Listener für mehrere ChoiceBoxen AWT, Swing, JavaFX & SWT 3
B eclipse für JavaFx setuppen AWT, Swing, JavaFX & SWT 4
A Swing JTextField an Button übergeben für Popup-Fenster funktioniert nicht AWT, Swing, JavaFX & SWT 3
H Ein Patten für das Gluon Mobile Framework AWT, Swing, JavaFX & SWT 7
J Gibt es einen Grund für 16x16 anstatt z.B. 15x15 Tiles ? AWT, Swing, JavaFX & SWT 10
F JFormattedTextField für kg und Währung AWT, Swing, JavaFX & SWT 6
V Swing für jedes Kästchen eine eigene Farbe AWT, Swing, JavaFX & SWT 2
F Wie bekomme ich den Wert der ComboBox in eine Variable gespeichert welche ich für meinen ActionListener nutzen kann? AWT, Swing, JavaFX & SWT 3
Soloeco JavaFX Dreifachklick für MenuButton erforderlich AWT, Swing, JavaFX & SWT 2
L JavaFX Lösungsvorschläge für dieses coole Control AWT, Swing, JavaFX & SWT 8
looparda Suche Lib für Visualisierung von Graphen AWT, Swing, JavaFX & SWT 12
G LayoutManager Beliebige Anzahl von Panels für LayoutManager AWT, Swing, JavaFX & SWT 3
L Ein Actionlistener für ein Textfeld, anstatt viele Actionlistener für ein Textfeld AWT, Swing, JavaFX & SWT 7
S Swing Finde Grund für NullPointerExeption nicht. AWT, Swing, JavaFX & SWT 2
W JavaFX (j)Unittests für GUI AWT, Swing, JavaFX & SWT 0
B JavaFX JavaFX TableView PropertyValueFactory für Werte aus HashMap AWT, Swing, JavaFX & SWT 2
SchmidiMC Swing Vorschläge für ein Design AWT, Swing, JavaFX & SWT 5
Z JavaFX Pane für wechselnde Sub-Panes mit Auto-Resize AWT, Swing, JavaFX & SWT 2
S 2D-Grafik affine Transformation für Text-Shape AWT, Swing, JavaFX & SWT 0
G Swing Variable Elemente für GroupLayout AWT, Swing, JavaFX & SWT 18
kodela Accalerator für einige Menüoptionen funktioniert nicht mehr AWT, Swing, JavaFX & SWT 3
P Swing Empfehlungen für einfaches Computerspiel AWT, Swing, JavaFX & SWT 4
L DragDropped für jede Node AWT, Swing, JavaFX & SWT 0
temi JavaFX Lösungsansatz für Umsetzung gesucht AWT, Swing, JavaFX & SWT 4
J Swing JavaProgramm für Verschlüssen für eine Datei AWT, Swing, JavaFX & SWT 19
D DatePicker für Java Swing AWT, Swing, JavaFX & SWT 2
MiMa Programmeinstellungen für Anwendung?? AWT, Swing, JavaFX & SWT 54
heinz ketchup While-Schleife in einem Service für GUI AWT, Swing, JavaFX & SWT 22
L JavaFX Renderer für JavaFX AWT, Swing, JavaFX & SWT 2
MiMa GUI Controller für Border Pane als MVC Modell AWT, Swing, JavaFX & SWT 1
L Font für Dashboard AWT, Swing, JavaFX & SWT 3
F Swing JColorChooser für die JToggleButtons AWT, Swing, JavaFX & SWT 5
S JavaFX Optimierung für verschiedene Auflösungen AWT, Swing, JavaFX & SWT 12
L JavaFX Animation für Panel wechsel AWT, Swing, JavaFX & SWT 3
T Swing Drag and Drop für JComponents AWT, Swing, JavaFX & SWT 1
Kloso Swing Pseudocode für Strafurzeichnung AWT, Swing, JavaFX & SWT 4
F Konstruktor für "Vier Gewinnt" AWT, Swing, JavaFX & SWT 10
L JavaFX PdfViewer für JavaFX Anwendung AWT, Swing, JavaFX & SWT 6
R Swing Welche LayoutManager sind die richtigen für mich? AWT, Swing, JavaFX & SWT 11
L Event Handling Gui für Taschenrechner AWT, Swing, JavaFX & SWT 27
C Slider für Zeitauswahl AWT, Swing, JavaFX & SWT 3
M Limit für JFrame-Vergrößerung AWT, Swing, JavaFX & SWT 8
GreenTeaYT Button funktioniert nicht für Ein-und Auszahlungen? AWT, Swing, JavaFX & SWT 8
K Liniendicke für Line Chart dynamisch ändern AWT, Swing, JavaFX & SWT 0
K JButton nicht sichtbar machen für User 2 AWT, Swing, JavaFX & SWT 4
OnDemand Gui Themes für FX AWT, Swing, JavaFX & SWT 4
G DefaultListModel für JList AWT, Swing, JavaFX & SWT 2
P JavaFX Kalender mit Kacheln für Ereignisse AWT, Swing, JavaFX & SWT 4
S ActionListener für alle Buttons AWT, Swing, JavaFX & SWT 26
J Swing Neuen Command für "show"? AWT, Swing, JavaFX & SWT 2
sandaime Swing Thread für CMD auslesen AWT, Swing, JavaFX & SWT 16
H Swing JFileChooser für nicht existierendes Unterverzeichnis AWT, Swing, JavaFX & SWT 3
R Java FX - Fxml - relative Größenangaben für Breite und Höhe einer TextArea AWT, Swing, JavaFX & SWT 8
D GUI-Bau für ein Auswertungs-Tool AWT, Swing, JavaFX & SWT 11
L Swing CellRenderer für einzelne Zellen? AWT, Swing, JavaFX & SWT 5

Ähnliche Java Themen

Neue Themen


Oben