ubuntuusers.de

Java: Anfänger hat Problem mit JComboBox

Status: Gelöst | Ubuntu-Version: Xubuntu 6.06 (Dapper Drake)
Antworten |

Margolwes

Avatar von Margolwes

Anmeldungsdatum:
3. September 2005

Beiträge: 394

Wohnort: Pliezhausen

Hallo,

ich habe als Java-Neuling ein kleines Progrämmchen mit Eclipse 3.2 geschrieben. Darin gibt es eine JComboBox und zwei JTextFields. Eigentlich funktioniert es auch prima, nur habe ich folgendes Problem: Wenn ich die Combobox auf setEditable setze, dann behält das Eingabefeld stur und steif den Eingabefocus. Gehe ich mit Tab oder Mausklick in eins der Textfelder, dann springt der Cursor zurück in die Combobox.

Hier der Quelltext.

Gruß, Margolwes

Marc_BlackJack_Rintsch Team-Icon

Ehemalige
Avatar von Marc_BlackJack_Rintsch

Anmeldungsdatum:
16. Juni 2006

Beiträge: 4694

Wohnort: Berlin

Bist Du sicher das Du alles "oben" in der Klasse wirklich als Klassenvariablen haben möchtest? Die Objekte werden erzeugt wenn Du die class-Datei lädst und nicht wenn ein Exemplar von Dialog erzeugt wird!

fzimper

Anmeldungsdatum:
17. September 2006

Beiträge: Zähle...

Hallo Margolwes,

Dein Code funktioniert bei mir.

Margolwes

(Themenstarter)
Avatar von Margolwes

Anmeldungsdatum:
3. September 2005

Beiträge: 394

Wohnort: Pliezhausen

@BlackJack: Wie gesagt, mache grade die ersten Gehversuche in Java. Wenn es nicht nach "oben" gehört, wohin denn dann?

@fzimper: Kannst du mir sagen, welche Java- und welche Eclipse-Version Du hast?

Vielen Dank, Margolwes

Margolwes

(Themenstarter)
Avatar von Margolwes

Anmeldungsdatum:
3. September 2005

Beiträge: 394

Wohnort: Pliezhausen

Ha, hab's rausgekriegt. Es war die falsche Java-Version. Jetzt würde mich aber immer noch interessieren, wo die Sachen "oben" eigentlich hingehören.

Gruß, Margolwes

Marc_BlackJack_Rintsch Team-Icon

Ehemalige
Avatar von Marc_BlackJack_Rintsch

Anmeldungsdatum:
16. Juni 2006

Beiträge: 4694

Wohnort: Berlin

Die gehören in den Konstruktor.

rydl

Anmeldungsdatum:
6. September 2005

Beiträge: 7

Die Objekte werden erzeugt wenn Du die class-Datei lädst und nicht wenn ein Exemplar von Dialog erzeugt wird!

ich glaub du meinst das richtige, aber das is so nich korrekt...
klassenvariablen sind schon statisch (zB "private static int X = 3") und werden beim start des programms (nicht beim "laden der class dateien") einmal erzeugt.
in dem source gibts allerdings nur ganz normale instanzvariablen (ohne static deklarierung). so wie es da steht ist das natürlich etwas unelegant...

nach dem starten des programms werden nicht einfach alle instanzvariablen (die dinger "oben") instanziiert, die in deinem source deklariert wurden. es gibt ja genau gesehen 2 schritte, die nötig sind eine instanz eines objekts zu erzeugen:

1. deklaration deiner variablen (zB "JTextField textField;" )
2. instzanziierung des objekts (zB "textField = new JTextField();" )

natürlich kann man das ganze auch in einem schritt machen, doch in deinem fall gibt es einen nachteil:
du hast keine kontrolle über deine instanzvariablen, deshalb schreibt man, bis auf wenige ausnahmen eigentlich alle deklarationen der instanzvariablen "oben" hin, ohne sie zu instanziieren und der konstruktor übernimmt dann diese aufgabe. wenn du für deine objekte mal mehre konstruktoren benutzt, wirst du den vorteil erkennen. dann wird dein programm eventuell etwas performanter, wenn nicht bei jedem "new" alle variablen erzeugt werden, sondern nur die, auf die es ankommt...

hoffe dir einen einblick in die programmierlogik gegeben zu haben 😉

user_unknown

Avatar von user_unknown

Anmeldungsdatum:
10. August 2005

Beiträge: 17622

Wohnort: Berlin

rydl hat geschrieben:

Die Objekte werden erzeugt wenn Du die class-Datei lädst und nicht wenn ein Exemplar von Dialog erzeugt wird!

ich glaub du meinst das richtige, aber das is so nich korrekt...
klassenvariablen sind schon statisch (zB "private static int X = 3") und werden beim start des programms (nicht beim "laden der class dateien") einmal erzeugt.
in dem source gibts allerdings nur ganz normale instanzvariablen (ohne static deklarierung). so wie es da steht ist das natürlich etwas unelegant...

nach dem starten des programms werden nicht einfach alle instanzvariablen (die dinger "oben") instanziiert, die in deinem source deklariert wurden. es gibt ja genau gesehen 2 schritte, die nötig sind eine instanz eines objekts zu erzeugen:

Das kann ich wiederlegen:

class A
{
	public static String foo = "A: static foo";
	static
	{
		System.out.println ("A: static initializer");
	}
}

class B
{
	public static String foo = "B: static foo";
	static
	{
		System.out.println ("B: static initializer");
	}
}

public class InitStaticsWhen
{
	public InitStaticsWhen (String param)
	{
		if (param.equals ("jetzt"))
		{
			System.out.println ("Loading A " + A.foo);
		}
		System.out.println ("Loading B " + B.foo);
	}

	public static void main (String args[])
	{
		String param = "jetzt";
		if (args.length == 1)
		{
			param = args[0];
		}
		new InitStaticsWhen (param);
	}
}


Zu starten mit

java InitStaticsWhen jetzt
java InitStaticsWhen nie


Schlußfolgerung: Nicht beim Starten des Programms, sondern beim Laden der Klasse werden statische Objekte erzeugt.
rydl hat geschrieben:

1. deklaration deiner variablen (zB "JTextField textField;" )
2. instzanziierung des objekts (zB "textField = new JTextField();" )

natürlich kann man das ganze auch in einem schritt machen, doch in deinem fall gibt es einen nachteil:
du hast keine kontrolle über deine instanzvariablen, deshalb schreibt man, bis auf wenige ausnahmen eigentlich alle deklarationen der instanzvariablen "oben" hin, ohne sie zu instanziieren und der konstruktor übernimmt dann diese aufgabe. wenn du für deine objekte mal mehre konstruktoren benutzt, wirst du den vorteil erkennen.

Und wenn nicht, dann nicht.
Es ist meistens nur eine Geschmacksfrage, und wenn es einen Unterschied macht, dann kann man es ja so machen, wie es in dem Falle richtig oder günstig ist.
rydl hat geschrieben:

dann wird dein programm eventuell etwas performanter, wenn nicht bei jedem "new" alle variablen erzeugt werden, sondern nur die, auf die es ankommt...

Wenn es auf manche Attribute manchmal nicht ankommt, dann verströmt das Design bereits einen verdächtigen Geruch.
Und das es die berühmte Ausnahme ist, die auch noch gleich performancekritisch ist - das klingt doch arg konstruiert.

fzimper

Anmeldungsdatum:
17. September 2006

Beiträge: 38

@user unknown: und jetzt lass mal das Wörtchen "static" weg, bei der Deklaration Deiner Klassenvariablen.

user_unknown

Avatar von user_unknown

Anmeldungsdatum:
10. August 2005

Beiträge: 17622

Wohnort: Berlin

fzimper hat geschrieben:

@user unknown: und jetzt lass mal das Wörtchen "static" weg, bei der Deklaration Deiner Klassenvariablen.

a) Dann sind es Membervariablen, und nicht Klassenvariablen - letztere sind immer statisch.
b) Früher initialisiert werden Membervariablen aber dennoch nicht, sondern später.

fzimper

Anmeldungsdatum:
17. September 2006

Beiträge: 38

a) Da hast Du Recht. Mir war die Definintion des Begriffs wohl nicht ganz klar, nur wie sich die verschiedenen Deklarationen auswirken.
b) Hab ich ja nie behauptet.

Antworten |