JAVA - focus setzen und Proxy ?

JAVA - focus setzen und Proxy ? (18 Beiträge, 108 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi !

Habe gerade ein Micky-MausProb und ein größeres:

1.) Focus setzen:
Klingt ja ur einfach, aber auf die schnelle habe ich es nicht gefunden:
Ich habe ein Eingabefenster (ist ein Singleton) - daß bei Aufruf mal korrekt befüllt wird.
Wenn es wieder geöffnet wird (also setVisible()) - ist der Fokus dort, wo er das letzte mal war - macht ja Sinn.
Ich möchte jetzt aber den Fokus auf ein fixes Element setzen - wie mache ich das (genauer auf ein JTextField).

2.) URL und so:
Meine Java-App ersetzt eine AJAX-Seite, via URL.openConnection und so verbinde ich mich und fetche meine Werte (was bisher die AJAX-Seite machte).

Jetzt habe ich aber das Problem, daß beim Client wohl öfter ein Proxy-Server sein wird.
Wie kümmerte man sich bis inklusive 1.4 um Proxy-Zugriffe ???

EDIT:

		form.pack();
		form.setLocationRelativeTo(main);
		form.setVisible(true);
		form.setModal(true);
		form.requestFocus();
		System.out.println(form.kundeNrFeld.requestFocusInWindow());

... habe ich versucht. requestFocusInWindow() liefert aber immer false... Welche Bedingung erfülle ich nicht ?

EDIT²:

	public static void erfasse(SuesselMainInterface main)
	{
		/*
		 * Solange dieses Fenster nur Modal aktiviert wird, kann es keinen Streß geben.
		 */
		
		if (form == null) {
			form = new AuftragEingabe();
			form.main = main;
			form.addWindowListener(new WindowAdapter() {
			    public void windowActivated(WindowEvent e) {
			        form.kundeNrFeld.requestFocusInWindow();
			    }
			});
		}

Nach diesem WindowListener klappte es - dann brauche ich natürlich auch das direkte form.requestFocus[|InWindow]() nicht...

Warum klappt es als Listener und nicht direkt ???

31.10.2006, 14:42 Uhr - Editiert von Linux_Sucks, alte Version: hier

Ad 1:
Das ist eh klar - aber nach der Doku:

requestFocusInWindow

protected boolean requestFocusInWindow(boolean temporary)

Requests that this Component get the input focus, if this Component's top-level ancestor is already the focused Window. This component must be displayable, visible, and focusable for the request to be granted. Every effort will be made to honor the request; however, in some cases it may be impossible to do so. Developers must never assume that this component is the focus owner until this component receives a FOCUS_GAINED event.

This method returns a boolean value.If false is returned, the request is guaranteed to fail. If true is returned, the request will succeed unless it is vetoed, or an extraordinary event, such as disposal of the component's peer, occurs before the request can be granted by the native windowing system. Again, while a return value of true indicates that the request is likely to succeed, developers must never assume that this component is the focus owner until this component receives a FOCUS_GAINED event.
.....

Die 2 fetten Sachen machen mich fertig - und damit mein ich diesmal nicht die Schwiegermutter+Schwester

Wenn das Teil false zurückliefert ist der Request garantiert schiefgegangen.
IMHO erfüllt aber mein CodeSnippet alle Vorgaben direkt nach dem setmodal(). Wieso klappt der Request also direkt danach nicht, aber beim WindowActivated-Event schon ????

Ad 2:
Grob habe ich ja

URL url= new Url("https://jfhdkfjshd:443/sdflksdl")..
...
url.connect()
...

und arbeite dann mit den Streams der Connection - das klappt.
Die URL selbst zeigt auf meinen Server - nona.

Jetzt ist es aber so, daß an einer Lokation ein Proxy dazwischenhängt - den man im IE, ... manuell konfigurieren muß a la "Proxy = proxy.interneslan:3128".

In Java 1.5 gibt's dazu URL.openConnection(Proxy proxy) - die einem das abnimmt.
Wie gings in Java 1.4 ???

Ergänzung:
Mir geht's eben genau darum, wie man von einem PC eine https-Verbindung zum Server schafft, wenn eben ein nicht transparenter Proxy dazwischen hängt...

Ad 1:
Den Link hatte ich bei google vorher schon gefunden - der half nicht...

Den IMHO erfüllt ja mein Form alle Bedingungen..
Solange mein Workaround geht, ist's mir eh nicht mehr so dringend - es ärgert halt nur, wenn man was nicht checkt... Hoffe, daß ich mich in Java net oft ärgern muß

Ad 2:
!!! Danke Schön !!! *Bier rüberreich*

Hoffe, daß es funktioniert.
Und das funktioniert implizit bei allen Verbindungen ? Das ist dann so ein Socks-Proxy, oder ?

Und wie geht das mit einem "nur-Http(s)-Proxy" ? Denn AFAIK ist ja meistens der HTTP(s)-Proxy kein SOCKS-Proxy...

Neues 3 einführ:
3a: Wie portabel sind die System.*Properties()-Gschichten ?
3b: Wie finde ich raus, welche Properties es auf allen Systemen (Also Handy bis zOS) gibt ?

Hi !

Ad 1:
<AFAIK>
Wir unterscheiden zwischen transparenten und intransparenten Proxies.
Bei einem transparentem Proxy hat der Client - den ich schreibe - eh nix zu tun. Wir behandeln also den intransparenten.

Hier hat der Client aber sehr wohl was zu tun, denn es sieht ja so aus - Sonderbehandlungen des Clients mach ich fett:
1.) Der Client baut eine Kommunikation zum Proxy auf (und authentifiziert sich notfalls gegenüber dem Proxy)
2.) Je nach Protokoll hat er einiges zu tun...
Bei HTTP hat er es einfach: Der Proxy (oft squid) wertet einfach das host-Field aus (aber erst bei HTTP/1.1(!)).
zB muß je nach Protokoll der Proxy den SSL-Handshake aufbauen, ...

Auch verhält sich ein SOCKS-Proxy anders als ein "normaler".
</AFAIK>
Drum vermutete ich, daß es u.U. ein SOCKS-Proxy sein muß.

Des weiteren bleibt mir unklar, wie das dann praktisch geht... Angenommen, mein Client baut 2 verschiedene Verbindungen auf (was er hier gottseidank nicht muß). Eine sei via JDBC zu einer Datenbank im Netz, eine sei via HTTPS zu einem Server. Die Proxy-Einstellung funktioniert ja "global" für die Applikation, oder ? Also würde dann auch der JDBC-Datenstrom zu meinem HTTPs-Proxy gehen, oder ????

Ad portabel:
Ich hätte meine App gerne so, daß sie in jeder beliebigen SUN-JavaVM ab 1.4 rennt... Meine Hauptziele sind dabei derzeit Linux und Windows, aber MacOS wird unbedingt erwartet. In näherer Zukunft wären Java-Handies eine Zielplattform (habe noch keine Ahnung, wie sich das mit dieser Micro-Edition-VM verhält... Dort wird aber sowieso Thema UI ein Wechsel passieren müssen). Die Frage wäre also konkret, ob diese "Proxy-Setzen via System.Properties"-Gschicht auch unter MacOS und Windows klappt.

FolgeFrage:
Meine Frage wäre - nun genauer:
Angenommen, meine Basis wären alle SUN-JavaVMs ab 1.4: Welche System-Properties gibt es auf den Standard-Betriebssystemen (Win2k*, Linux, AIX, Solaris) - und welche nur auf manchen Plattformen ? Wie kriegt man das raus ? Auf einer (zugegeben kurzen) suche bei java.sun habe ich das nicht gefunden.

Abschluß:
Zumindest HTTP-Traffic konnte ich mit deiner Lösung schon testen - klappte superfeinst !!! DANKE!
Ob HTTPs damit auch klappt, muß ich noch getrennt testen...

Hi !

Genau in der API-Doku treibe ich mich eh dauernd rum - ich habe es inzwischen aufgegeben, in Büchern zu graben.... Denn die mir bekannten Bücher (http://www.javabuch.de , http://www.galileocomputing.de/openbook/javainsel5/ ) sind zwar didaktisch besser, aber bei weitem nicht ausreichend

Den Sun-Api-link von Dir kannte ich also eh... ABER:

Genau das Wort "proxy" taucht aber in beiden Links net auf...
Und mein Ansatz war eben, daß die API-Doku von SUN die einzige verläßliche ist...

Nachdem dort steht "This set of system properties always includes values for the following keys:"" bedeutet das ja nur, daß es eben scheinbar nicht immer (also nicht auf allen 1.4er JREs) die Proxy-Möglichkeit gibt, oder ???

Auch in den SUN-Networking-Tutorials werden Proxies mit keiner Silbe erwähnt - drum meine Portabilitäts-Frage

Auf jeden Fall ein Riesiges DANKESCHÖN mit Zuckerguß und Streuserl drauf....

EDIT:
Bedenklich finde ich aber, daß eine Suche bei SUN nach proxyset genau 0 Hits bringt:
http://onesearch.sun.com/search/onesearch/index.jsp?qt=proxyset&x=0&y=0&charset=utf-8&col=developer-reference&rt=true&cs=false

02.11.2006, 11:31 Uhr - Editiert von Linux_Sucks, alte Version: hier

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung