GUI: Ich brauche ein Textfeld mit "Sperre"

[hdi]

Hey, doofer Titel, aber ich hab keine Ahnung wie man sowas nennt...
Ich hatte in die Richtung schon mal etwas gefragt gehabt, aber irgendwie ist nix bei rausgekommen, also versuche ich es noch einmal.

Aus diversen Gründen brauche ich ein Textfeld, dass jegliche User-Interaktion mit der GUI verhindert, solange der Inhalt nicht valide ist. Es geht darum dass der User Datensätze editieren kann, aber ich will sicherstellen dass er keinen Mist abspeichert. Wenn er jetzt also in ein Textfeld hineinklickt, soll die komplette GUI gesperrt werden, solange bis er zB "Enter" drückt. Und nur wenn der Inhalt dann eine bestimmte Validitäts-Prüfung bestanden hat, soll das abgespeichert und die GUI wieder freigegeben werden. Solange das aber nicht der Fall ist, wird der User gezwungen etwas anderes einzugeben.
(Keine Angst, ich hab nicht vor sowas in ein Quiz oder etwas ähnliches einzubauen, was dann zu einem nicht-beendbaren Programm führt )

...am besten mit diesem typischen "Bing"-Ton, den Windows von sich gibt wenn eine bestimmte Eingabe oder Aktion nicht passt.
So nach dem Motto: "Wenn du diesen Raum betrittst, bleibst du solange da drin bis ich sage du darfst raus".

Ich kann zwar natürlich sicherstellen, dass der Datenbestand intern okay ist, in dem ich etwas einfach nicht abspeichere. Aber das ist nicht wirklich user friendly, denn es kann dann dazu führen dass der User denkt er hat etwas gespeichert, aber in Wahrheit ist das gar nicht passiert. Das Problem ist halt das man jederzeit einfach ein Tab wechseln kann oder auf das Menü des Frames klicken usw.. Dann verliert das Textfeld den Fokus, es wurde nix gespeichert aber der Text im Textfeld wird so angezeigt wie der User ihn eingegeben hat. Das ist halt doof.

Also.. wie kann ich mir sowas am besten machen?

Ich wäre echt sehr dankbar für Hilfe, weil ich sitz an dem Mist schon seit mehreren Wochen -.-

 

[Spacerat]

Ganz banal und möglicherweise auch nicht unbedingt der Stein der Weisen, aber mit einem [c]FocusListener[/c] an das Textfeld gehängt könnte das was werden. Bei [c]focusLost()[/c] Eingaben überprüfen und diesen ggf. mit [c]requestFocus()[/c] wiederholen.

 

[hdi]

Ne das hab ich alles schon durch, diese ganzen requests usw. sind viel zu "nett". Es hindert niemanden daran einfach das komplette Tab, in dem das Textfeld drinsteckt, zu wechseln oder schließen.

 

[Spacerat]

Sag' ich doch... nicht der Stein der Weisen...
Ein Tab? Dabei kann es sich doch höchstens um einen Container handeln, der sich irgendwo in einem Window befindet. Also: Um die Idee noch nicht ganz at Acta zu legen, [c]focusGained()[/c] könnte dafür sorgen, das dieses Window nicht mehr geschlossen werden kann, indem es dort z.B. eine Variable setzt, die das Verhalten des [c]WindowListeners[/c] entsprechend korrumpiert (boah wat' 'ne Wortwahl... hoffe du verstehst was ich meine).

 

[hdi]

Naja aber ich will ja mehr als nur verhindern, dass das Window geschlossen wird: Sämtliche Komponenten darin sollen nicht mehr reagieren. Ich befürchte es geht nur mit nem modalen Dialog (undecorated, der aussieht wie das Textfeld, den Inhalt enthält, und genau dort erscheint, wo das Textfeld ist Oo). Aber das is....nich so gut ^^

 

[Spacerat]

Versteh' ich nicht... Wieviele Komponenten innerhalb eines Fensters (oder überhaupt) können denn gleichzeitig den Fokus haben? Doch nur eine, oder nicht? Und wenn sich genau diese Eine den Fokus immer wiederholt, solange ihr Inhalt nicht stimmt kann doch gar nichts passieren, denn Eingaben können doch nur beim Focus-Owner gemacht werden. Für mich wird's erst mal Zeit für schief gehende Experimente...

 

[hdi]

Oh ja das ist ja auch noch ein Problem :autsch:: Ich hab mehrere solcher Textfelder.. Das heisst wenn ich zB per Tab-Druck aus einem rausspringe, spring ich evtl ins nächste. Und dann geht das Battle um den Fokus los

... am besten aber ich zeig euch mal meine Applikation, dann seht ihr den Zusammenhang, und vllt fällt euch ja eine ganz andere Herangehensweise ein.

Hier ist meine App:
RapidShare: 1-CLICK Web hosting - Easy Filehosting
Alternativ-Link (falls es bei RS schon 10x runtergeladen wurde):
http://www.filedropper.com/lmdb16

Erstellt einfach mal nen Film dann könnt ihr ihn editieren.
Die Filterfunktion funktioniert hier noch nicht, nur das Editieren im "Film-Details" Tab. Aber ihr seht halt wie das aussieht und dann versteht ihr vllt mein Problem.
Kritische Momente wären zB das Bearbeiten des Titels, der nicht leer sein darf. Oder das Jahr, das eine gültige Zahl haben muss.
Im Moment mach ich einfach ein Reset wenn der Wert nicht passt, und lass das Feld kurz aufleuchten. Aber erstens behebt das nicht das Problem dass ich mit dem Filtern bekommen würde, und zweitens ist auch das nicht so cool weil man jederzeit nen anderen Film anklicken kann und z.T. wird das dann nicht gespeichert.

...bitte einfach mal starten und überlegen wie ihr das machen würdet, sodass es DAU-kompatibel ist, und natürlich möglichst einfach (sowohl für den User als auch für die Implementierung)

Ich freu mich über jeden Tipp! Danke!

PS: Das Programm legt beim ersten Start ein neues File in dem Ordner an, aus dem es gestartet wird. Das könnt ihr nach dem Rumspielen auch gleich löschen. (ist die "Datenbank" die eure Filme enthält)

PPS: bitte nicht auf andere Dinge eingehen, ich weiß dass es auch sonst noch einiges zu Verbessern gibt, ich arbeite auch schon an einer 2ten Version, aber da bin ich noch nicht so weit dass ich euch jetzt die Problematik veranschaulichen kann.

 

[Spacerat]

Da... Bitte... Mach was draus...

import java.awt.Color;
import java.awt.Frame;
import java.awt.GridLayout;
import java.awt.TextField;
import java.awt.event.FocusEvent;
import java.awt.event.FocusListener;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;

public final class CriticalTextFields
{
	public static void main(String[] args)
	{
		final Frame f = new Frame("CriticalTextFields");
		f.addWindowListener(new WindowAdapter()
		{
			@Override
			public void windowClosing(WindowEvent e)
			{
				System.exit(0);
			}
		});
		f.setLayout(new GridLayout(5, 1, 5, 5));
		f.setBackground(Color.GRAY);
		for(int n = 0; n < 5; n++) {
			f.add(new CriticalTextField());
		}
		f.pack();
		f.setVisible(true);
	}
}

class CriticalTextField
extends TextField
{
	private static final long serialVersionUID = 1L;
	private static final FocusLock focus = new FocusLock();

	{
		addFocusListener(new FocusListener()
		{
			private final CriticalTextField tf = CriticalTextField.this;

			public void focusLost(FocusEvent evt)
			{
				synchronized(tf) {
					if(check()) {
						try {
							synchronized(focus) {
								focus.unlock(tf);
							}
						} catch(UnlockException exc) {
						}
						return;
					}
					try {
						synchronized(focus) {
							focus.lock(tf);
						}
						tf.requestFocus();
					} catch(LockException exc) {
					}
				}
			}
			
			public void focusGained(FocusEvent evt)
			{
			}
		});
	}

	private boolean check()
	{
		return "test".equals(getText());
	}
}

class FocusLock
{
	private CriticalTextField field;

	public void lock(CriticalTextField obj)
	throws LockException
	{
		if(obj != null) {
			if(field != null && field != obj) {
				throw new LockException();
			}
			field = obj;
		}
	}

	public void unlock(CriticalTextField obj)
	throws UnlockException
	{
		if(obj != null) {
			if(field != null && field != obj) {
				throw new UnlockException();
			}
			field = null;
		}
	}
}

class LockException
extends Exception
{
	private static final long serialVersionUID = 1L;
}

class UnlockException
extends Exception
{
	private static final long serialVersionUID = 1L;
}

Zu deiner gehosteten Anwendung: Iwie habe ich da nicht eine Zeile Quelltext gefunden. Aber was soll's. Obiges Beispiel locked zumindest schon mal die einzelnen Textfelder. Mir ist auffgefallen, das die Enter-Taste die Textfelder auch dann nicht weiterschaltet, wenn die Eingabe korrekt ist. Ist das normal?

 

[KrokoDiehl]

Ich würde vom FocusListener weggehen und mich mit InputVerifier beschäftigen Hier kann man einen eigenen schreiben und die Methoden

verifiy()

und

shouldYieldFocus()

entsprechend überschreiben. Dann geht der Cursor auch erst aus dem Feld, wenn man dort true zurückgibt, ohne dass man den Fokus hin und her setzen muss.

Das Problem bei den Verifiern ist, dass er ggfs nicht immer aufgerufen wird, zB wenn man in ein Menü klickt. Das kann man aber über die JComponent-Methode

setVerifyInputWhenFocusTarget()

steuern.
So wie ich's verstehe bräuchte also jede andere Komponente (die den Fokus haben kann) diesen Wert auf true

 

[Spacerat]

Das Problem bei den Verifiern ist, dass er ggfs...

Ist das die feine englische Verkaufsstrategie? Jemandem etwas "Verkaufen" wollen, womit es möglicherweise Probleme gibt? :lol:
Aber hey... Immerhin 'ne Idee, die besser aussehen könnte als meine, zumal ich diese Möglichkeit noch gar nicht gesehen habe, [c]InputVerifier[/c] also nicht kannte. Iwie werd' ich das Gefühl nicht los, dass die zu verifizierende Komponente im Gegensatz zu meiner Lösung über die anderen involvierten Komponenten Bescheid wissen muss.

So wie ich's verstehe bräuchte also jede andere Komponente (die den Fokus haben kann) diesen Wert auf true

Rein intuitiv steuert man den Fokus halt über Listener. Ob das mit der Synchronisierung der Listener Methode allerdings sein muss... kA. Ich denke mal nicht, zumal es nur einen EDT gibt. Beim [c]FocusLock[/c] aber bin ich sicher... die gehört so.

 

[JohannisderKaeufer]

Einen JDialog kann man doch auf modal setzen und somit die restliche GUI sperren.

Das Klingt für mich zumindest mal nach einem Lösungsansatz, bzw. wenn man die Sourcen dazu anschaut könnte man eine Lösung daraus ableiten wie man ein Textfield modal setzt.

Eine weitere Möglichkeit könnte sein direkt mit einem Dialog zu arbeiten, bzw. einen Dialog derart umzubauen, damit er das gewünschte tut.

 

[KrokoDiehl]

Ist das die feine englische Verkaufsstrategie? Jemandem etwas "Verkaufen" wollen, womit es möglicherweise Probleme gibt?

Klar, hdi soll ja beschäftigt bleiben

Aber im Ernst. Wir hatten das im aktuellen Projekt auch zuerst via FocusListener. Das tat größtenteils auch, aber Problem war in manchen Fällen, dass

focusGained()

und

focusLost()

erst aufgerufen werden, wenn der Fokus schon da, bzw. weg ist und ein

requestFocus()

führte dann manchmal zu Endlosschleifen. Ok, mit nem Fokus-Lock haben wir es nie probiert.
Die InputVerifier werden ausgeführt, bevor eine Komponente den Fokus verliert (hat mich auch einiges an googlen gekostet), was wesentlich entspannter abläuft, allerdings auch restriktiver für den Benutzer.

Dann kam bei uns aber das Problem, dass man in nem Feld war, und nicht mehr ins Menü klicken durfte, weil beim Klick aufs Menü der Fokus kurz herausspringt, was laut InputVerifier aber verboten war. Aber dafür gibts ja die o.g. Methode Ich weiß aber leider nicht, was die Standardeinstellung für diese Eigenschaft bei den jeweiligen Komponenten ist.

 

[Spacerat]

Naja... Bei meinem Beispiel kann man der [c]check()[/c]-Methode immerhin noch die Quelle des Events die den Fokus haben wollte mit übergeben und so explizit filtern, ob man dieser den Fokus überlässt. Ich wüsste blos nicht, wie sich das Textfeld den Fokus dann zurückholen sollte, wenn die Quelle diesen wieder abgibt. Aber da fällt mir sicher auch noch was zu ein.