Schriftgröße bei EtchedBorder()

[Alex_winf01]

Ich habe ein Panel wie folgt formatiert:

aufnahmebedingungen.setBorder(new TitledBorder(new EtchedBorder(),"Vorstellungs-/Aufnahmebedingungen"));

Nun möchte ich gerne die Überschrift "Vorstellungs-/Aufnahmebedingungen größer haben (Schriftgröße 16). Leider funktioniert das nicht nach dem Motto

aufnahmebedingungen.setFont(schrift);

Wer kann mir helfen?

 

[wayne]

der titel deiner post ist falsch :noe:

eine EtchedBorder hat keinen titel. aus deinem quelltext geht aber hervor, daß du die schriftart/-größe der TitledBorder verändern willst. mach doch mal folgendes:

TitledBorder titledBorder = new TitledBorder(new EtchedBorder(),"Vorstellungs-/Aufnahmebedingung"));
titledBorder.setTitleFont(new Font("Arial",Font.PLAIN,12);
aufnahmebedingungen.setBorder(titledBorder);

viel erfolg

wayne

 

[Alex_winf01]

@ wayne

Vielen vielen Dank für den Hinweis. So funktioniert das. Und ich kann auch endlich den Rahmen bearbeiten!!!

Ein wirklich tolles und kompetentes Forum. :applaus:

Noch was: Sorry, für meine Fehler. Schäm, in die Ecke gloz.

Kannst Du mir vielleicht auch sagen, ob mehrere Anwender gleichzeitig ein Jar-File öffnen können?

 

[wayne]

klar geht das. jeder anwender greift dann zwar auf das selbe jar-file zu aber nur lesend. jeder benutzer hat auf seiner workstation oder auf ein und der selben workstation also javaw.exe oder java.exe in einem eigenen speicherbereich auszuführen. die trennung der programme übernimmt, bei gleicher workstation, das betriebsystem. noch leichter wird das, wenn dein jar-file ein applet beinhaltet, da dieses ja zunächst in den browser-cache kopiert wird, bevor es ausgeführt wird. es gibt bei alle dem nur eine einzige einschränkung. wenn dein quelltext auf andere resourcen exklusiv zugreift. beim schreiben in datenbanken ist das normalerweise noch kein problem, da die datenbank hier zwischen den zugreifenden instanzen unterscheidet. da musst du nur beim programmieren aufpassen, ob der datensatz, welchen du überschreiben oder löschen willst, noch existiert. beim zugriff auf dateien, insbesondere auf das jar-file selbst, wird die sache dann aber wirklich kompliziert. wenn jeder nutzer in seinem nutzer-cache eine temporäre datei angelegt bekommt, geht das. greifen jedoch alle benutzer durch das jar-file auf ein und die selbe datei zu, wird dir das betriebssystem warscheinlich einen strich durch die rechnung machen und den zugriff verweigern. bei schreibenden zugriffen auf das jar-file selbst kann es im ungünstigesten fall zu abstürzen oder exceptions kommen oder das betriebssystem meckert auch hier vorher. aber solange du nur das jar-file ausliest und dorthin keinen OutputStream öffnest, hast du kein problem.

viel erfolg

wayne

 

[Alex_winf01]

@ wayne

Danke schon mal für Deine Antwort. Also ich hatte es mir wie folgt vorgestellt: Das Jar-File liegt irgendwo auf einer Festplatte im Netzwerk (z. B. Laufwerk z:/meinProgramm-Ordner/meinProgramm.jar oder e:/). Fünf Anwender greifen auf das JAR-File zu, geben Daten ein, die in einer hsqldb-Datenbank, die sich wiederum unter z:/meinProgramm-Ordner/ befindet (jedoch nicht im jar-File).

Geht das überhaupt?

 

[wayne]

ja, die lokation der datenbank wird ja mittels netzwerk-adresse festgelegt. mit der datenbank unterhält sich dein programm also genau so, als wäre es eine datenbank, welche sich irgendwo im internet befinden würde. das ist von dem her auch vollkommen wurscht.

die nutzer können selbstverständlich alle auf das jar-file zugreifen, denn, wie gesagt, das betriebssystem wird dir hier beim lesezugriff nicht dazwischen pfuschen, schließlich ist es ja nicht das jar-file, sondern javaw.exe oder java.exe, welches vom betriebssystem ausgeführt wird.

das einzige problem kann sich dann nur noch in der datenbank abspielen. hier können alle typischen datenbankprobleme auftreten, beispielsweise wenn ein benutzer einen datensatz löscht, ein anderer diesen aber gerade bearbeitet. das liegt letztlich dann an dir eine intelligente programmierung im jar-file vorzunehmen, die derlei dinge ausschließt oder ggf. abprüft, sofern dies möglich ist. falls derlei vorgehen nicht geht gibt es halt fehlermeldungen die du dem benutzer entgegenschleuderst oder du überlegst dir, was das sinnvollste vorgehen wäre. in dem genannten beispiele könntest du, wenn benutzer1 den datensatz löscht, welchen benutzer2 gerade bearbeitet, durch eine grundlegend eingeführte weitere spalte in der tabelle das löschen durch benutzer1 unterbinden, da das öffnen und bearbeiten von benutzer2 ein entsprechendes flag in besagter zusatzspalte gesetzt hat. andere lösung für dieses problem wäre, daß nach dem bearbeiten benutzer2 speichern drückt und dein programm zunächst überprüft ob der datensatz noch existiert, wenn ja, dann eben ein update durchführt und wenn nein, ein insert.

wayne

 

[wayne]

hab grad bei ner zigarette bissi darüber philosophiert. ich meine, daß du dir die frage schon stellen solltest, ob du nicht ein applet anstatt einer applikation schreibst. vorteile des applets: die benutzer müssen nicht den pfad kennen und auch nicht die startparameter. sie rufen eine html-datei auf einem webserver auf und diese verlinkt auf das applet mitsamt aller startparameter, ggf. sogar mit user und passwort, wenn deine webseite entsprechend gestrickt ist. einen webserver aufsetzen ist nicht das problem, problematisch ist es nur das teil abzudichten, daß die user beispielsweise keine programmdateien klauen können. aber bei einem internen unternehmensnetz mit einer so begrenzten nutzerzahl ist das eigentlich nicht das problem. und ein applet unterscheidet sich kaum von einer applikation. anstatt einer klasse, welche eine main(...)-methode beinhaltet lässt du deine klasse von Applet oder JApplet erben und verteilst die aufrufe, welche du in main(...) stehen hast, in jbinit() und start(), je nachdem, welche aufrufe nur zu initialisierung und welche zum tatsächlichen ablauf gehören. jbinit() sollte normalerweise beispielsweise beispielsweise den aufbau der gui beinhalten. bei meinen bisher geschriebenen applets blieb start() bis auf eine ausnahme leer. die eine ausnahme war ein applet, welches selbst nach einem benutzernamen und passwort gefragt hat und in start stand bei mir der code, damit das textfeld für den benutzernamen sofort den tastaturfokus hat.

letztlich bleibts deine sache und mit einer applikation funktioniert das natürlich auch. nur der benutzer wird sich, denke ich, mit einem applet leichter tun.

viel erfolg

wayne

 

[Beni]

Vielleicht wäre auch Webstart eine Lösung: da bekommt der Benutzer nur eine URL zu einer JNLP-Datei, und sobald er auf diese URL klickt, wird die Applikation automatisch von einem Server geladen und gestartet. Man kann damit ein Applet umgehen (ist somit nicht auf den Browser beschränkt), und muss die JAR trotzdem nur einmal speichern.