perdian

Sowas habe ich bisher noch nie gesehen. Vom ViewPort sollte man eigentlich die Finger lassen - es sei denn, man weiss genau, was man tut. Probier einfach mal: jp = new JScrollPane©;

Sicher? Dieser Klicksound wird eingestellt unter "Windows Explorer" -> "Navigation starten"

doskey /reinstall

Du solltest dich ein bisschen mit LayoutManagern auseinandersetzen, damit erhälst du nämlich genau die Effekte, die du haben willst. Du musst dir als erstes (ruhig auf einem Blatt Papier) überlegen, welche Bereiche hast du, und wie genau sollen diese Bereiche aufgeteilt sein. Als nächsten Schritt gilt es dann einen LayoutManager zu finden, der genau diese Aufteilung erreicht. Dein aktuelles Problem sollte sich eigentlich so lösen lassen (ungetestet): public static void main(String[] args) { // Desktop erzeugen JDesktopPane desktopPane = new JDesktopPane(); desktopPane.setBackground(Color.GRAY); // Toolbar für Button(s) JPanel buttonPanel = new JPanel(new FlowLayout(FlowLayout.LEFT)); buttonPanel.add(new JButton("Drück mich!")); // Haupt-Panel JPanel contentPane = new JPanel(new BorderLayout()); contentPane.add(buttonPanel, BorderLayout.NORTH); contentPane.add(desktopPane, BorderLayout.CENTER); // Menü erzeugen JMenuBar menuBar = new JMenuBar(); JMenu menu = new JMenu("Menü"); JMenuItem menuItem = new JMenuItem("Drück mich"); menu.add(menuItem); menuBar.add(menu); // Frame erzeugen JFrame frame = new JFrame(); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setJMenuBar(menuBar); frame.setContentPane(contentPane); frame.setSize(400, 200); frame.setLocation(10, 10); frame.setVisible(true); }

Du solltest dich als allererstes genauer mit Linux befassen, damit du weisst, was du an deinem System "schrauben" musst, damit alles funktioniert - sonst wirst du immer wieder auf (scheinbar unlösbare) Probleme stoßen. http://www.selflinux.org/

Dann einfach als root anmelden und die Rechte wieder hochsetzen.

Poste bitte mal den kompletten Quellcode, wo dein GUI erzeugt wird. So bringt die Fehlerbeschreibung nix.

"You don't have permission to access / on this server." Was sollte denn statt dessen angezeigt werden? index.html oder index.php existiert nicht, also was ist das erwartete Verhalten?

Gegenfrage: Kannst du schonmal das, was du bisher hast posten?!

Nein! So, wie du es haben willst ist es nicht möglich. Mache dich mit dem Konzept eines Webservers, und was eine URI ist vertraut und du wirst merken, dass es nicht geht. Du könntest den Apache so konfigurieren, dass er Verzeichnis-Listing zulässt. Dieses Listing kannst du dann unter Java einlesen, parsen und auswerten, was für Dateien vorhanden sind. Diese Dateien kannst du dann wiederrum per URL einlesen und du kommst an deine Daten. Aber sowas wie dieses hier wirst du nie erreichen: URL someURL = new URL("http://localhost/somewhere/"); URL[] fileURLs = someURL.listChildren(); Wenn schon, dann muss der Webserver so konfiguriert sein, dass er dir die Info gibt, welche Dateien vorhanden sind (z.B. über Directory Listing). Eine allgemeine Lösung, um an alle möglichen URLs eines Servers zu kommen gibt es nicht, da kannst du noch so oft rufen "Irgendwie muss es gehen".

Es geht nicht. So einfach ist das Wenn du per URI auf eine Datenquelle zugreifst (und wenn ich dich richtig verstanden habe willst du das), dann kannst du "direkt" keine Liste von verfügbaren Files bekommen - weil man nie wirklich wissen kann, wieviele Files denn "auf der anderen Seite" verfügbar sind. Kleines Beispiel: Es müssen ja keine wirklichen Dateien sein. Eine URI wie /localhost/view/product/001.jsp könnte der Webserver interpretieren als "Ziehe Produkt 001 und generiere eine HTML-Seite, die den Inhalt anzeigt". Da aber ständig neue Produkte hinzukommen oder wegfallen kannst du eigentlich gar nicht sagen, wieviele "Files" es tatsächlich auf dem Server gibt (denn es sind ja keine echten Dateien).

Naja das Konzept an sich ist schon in Ordnung - man muss natürlich immer aufpassen, dass man sich nicht selber zum Sklaven eines solchen Konzeptes machen lässt. Normalisierung ist gut und wichtig, aber genauso wichtig ist es, zu erkennen wo man damit aufhören sollte, bzw. ganz bewusst bestimmte Nachteile in kauf nimmt. Ich hatte vor ca. einem Jahr solch einen Fall gehabt: Eine Produktdatenbank mit Properties. Anzahl der Produkte: ca. 50.000 Properties pro Produkt: ca. 100 Ganz logisch, die Properties lagern wir in eine eigene Tabelle aus. So weit, so gut. Aber als dann der erste Import der Produktdaten durchgelaufen war, stellte sich heraus, dass eine Abfrage auf der Datenbank über knapp 5 Millionen Properties Einträge schon im Bereich von 10-20 Sekunden lag. Und das war für den konkreten Einsatzbereich einfach zu viel. Die Daten mussten schnell angezeigt werden, da es eine komfortable Eingabemaske zur schnellen Datenänderung sein sollte. Und was hilft mir die komfortabelste Maske, wenn ich 90% der Zeit mit dem Warten auf die Daten verbringe? Kurzum, da musste dann halt anti-normalisiert werden. Die Properties wieder mit zurück in die Artikeltabelle und schwups - die Query war runter auf ein paar Millisekunden. Das Konzept kann also noch so toll sein - wenn es die Erfordernisse aus der Praxis nicht abbilden kann, dann ist es schlicht und ergreifend nicht brauchbar.

Gibt es nicht! Das ist wohl für jede Applikation unterschiedlich. Bestimmte Standard-Installer haben zwar auch Standard-Parameter, aber letzten Endes kommt das vollkommen auf die Applikation an, wie die Parameter ausgewertet werden.

Eben! Es bringt nichts, da noch weiter normalisieren zu wollen. Es geht einfach nicht. Du bekommst hinterher keine "bessere" Tabellenstruktur raus, sondern im Gegenteil. Ich bekomme nichts als eine weitere bijektive Abbildung ID <-> Datum. Wenn zwei Felder in zwei Datensätzen dengleichen Wert haben, dann heisst das noch lange nicht, dass normalisiert werden muss. Ich kann auch anfangen Nachnamen zu normalisieren. Müller z.B. soll ja in Deutschland durchaus mehrfach vorkommen - also ab damit, in eine Lastname Tabelle, und vom Kunden nur noch referenzieren. "Vollkommener Quatsch" wird jetzt jemand rufen aber genauso ist das mit dem Datum aus. Nein, das Datum ist sogar noch viel besser dran, bei 200x Müller-Lüdenscheid -> Id 205 spare ich sogar noch was an Speicherplatz. Und während in Villariba noch normalisiert wird, wird in Villabacho schon das Produkt verkauft

Für mich das beste Package für dynmische Menüs: http://sourceforge.net/projects/doimenu

Das Datum auszugliedern ist eigentlich gar nicht möglich. Wieso? Es ist schon atomar, und eine ID für ein Datumswert wäre ein vollkomme unnütze Redundanz! 06.05.2005 - wie will ich das denn noch weiter aufsplitten? Letzten Endes kann man ein Datum auch "nur" wie einen normalen Integer betrachten (und AFAIK läuft das bei vielen Datenbanken intern auch so), in diesem Fall wäre es halt 20050506 Und jetzt muss mir schonmal jemand sagen, wie ich das noch in eine eigene Tabelle ausgliedern will. Klar, theoretisch möglich wäre sowas: ID Datum 1 01.01.2005 2 02.01.2005 ... Aber wo ist dann der Witz bei der ganzen Geschichte? Es bringt mir nicht mal Speicherplatzvorteile. Naja, wenn ich nur 10 Tage verwalte, dann kann die ID vielleicht als short und das Datum selbst als int laufen - aber das ist schon sowas von vernachlässigbar, dass ich nichtmal dran denken will Generell zur Normalisierung, dort ist es wie mit vielen Dingen: Sehr sinnvoll, aber man kann auch alles übertreiben.

Professioneller Test... von der Bild-Zeitung...

Das kann man so pauschal nicht sagen. Es kommt darauf an, was du mit der Datenbank genau anstellen willst. Für viele tausend Queries pro Sekunde brauchst du vielleicht eine andere Datenbank im Hintergrund, als für ein paar Inserts und Updates alle sieben Pfingsten. Datenbank X ist ideal wenn es darum geht Transactions zu managen, bei Datenbank Y kann ich hingegen ideal Benutzerrechte vergeben - die Anforderungen sind da ganz unterschiedlich. Der Overhead des Zugriffes von Applikation zur Datenbank kann in der Regel vernachlässigt werden, da macht sich manch einer viel zu viel Gedanken drüber. Ist zwar gut und schön, sich darüber den Kopf zu zerbrechen, aber in 99% der Fälle liegt der Flaschenhals nicht in der Verbindung zur Datenbank selber, sondern in der Tabellenstruktur und/oder dem Aufbau der Statements.

Mach es so, wie du es für richtig hälst, und du glaubst, dass es gut ankommt. Bei kaum etwas anderem gibt es so verschiedene Ansichten wie bei "guten" Bewerbungen. Geh zu drei verschiedenen Leuten (auch professionellen Job-Beratern) und du wirst drei verschiedene Ansichten hören, was wirklich gut und professionell ist. In der Regel widersprechen sich diese Aussagen auch noch. Ich würde mir um solche Kleinigkeiten keine Gedanken machen - die Bewerbung muss überzeugend rüberkommen, dabei ist es für mich egal, ob jetzt die Seitenränder nach DIN-12345 korrekt sind, oder die Unterschrift nun in Druckbuchstaben oder Krickelkrakelschrift zu lesen (bzw. nicht zu lesen) ist.

Dokus zum Thema WLAN lesen und verstehen, was es alles einzurichten gilt, damit nicht jeder "mitmachen" kann. Wenn du das wirklich verstanden hast, dann brauchst du eigentlich keinen Test mehr, weil du eh bescheid weisst.

Beide Male und überhaupt nicht Im ernst: Es gibt keine besseren und schlechteren Zeiten. Jede Firma wählt für sich zu anderen Zeiten neue Mitarbeiter aus. Die Jahreszeit spielt da wohl nur eine sehr untergeordnete Rolle. Für deine Wahl sollte sich das aber überhaupt nicht tun, den mit sowas kannst du nicht planen. Bewerbe dich zu dem Zeitpunkt, wo du fertig wirst - und nicht dann, wenn du glaubst, dass dort die Lage am besten wäre.

Lesen bildet: http://www.google.com/search?hl=de&ie=ISO-8859-1&q=charset+tabelle+mysql

Das ist dein Bekanntenkreis. Wenn ich das mal genauso ansehe und mal schaue, wer denn so von den FIs, die ich kenne arbeitslos ist und wer noch einen Job hat, dann fällt mir im Moment niemand ein, der auf Straße sitzt - da sind alle in Lohn und Brot. Die Realität liegt irgendwo zwischen diesen beiden Erfahrungen. Natürlich ist es nicht so, dass dir die Firmen die Tür einrennen und dich geradezu anflehen "Bitte bitte, arbeite für uns". Diese Zeiten sind vorbei. Aber genausowenig wird das KnowHow eines gut ausgebildeten IT'lers nirgendwo mehr gebraucht. Inzwischen ist halt doch wieder Wissen gefragt: Die Zeiten, wo du dir einen Abend ein HTML und einen anderen Abend ein PHP Buch zuhause durchgelesen hast und danach sofort einen Job bekommen hast sind (zum Glück) Vergangenheit. Aber das heisst noch lange nicht, dass nirgendwo mehr Software-Entwickler/Sysadmins/whatever benötigt werden. Deshalb generell zu sagen "FI zu lernen ist eine Garantie für's Arbeitsamt" ist kompletter Quatsch.

Im HTML-Quellcode: <html> ... <form name="form1"> <select name="selectBox"> <option value="1">1</option> </select> </form> ... </html> und das JavaScript dazu: function selectEntryFromBox(var entryNumber) { var theBox = document.form1.selectBox; selectBox.selectedIndex = entryNumber; }

Von Haus aus (also mit java.util.zip) kannst du ein ZIP schonmal nicht verschlüsseln. Wenn du das ZIP nicht mit einem anderen ZIP-Programm sondern nur aus der Application heraus lesen willst würde ich direkt die Streams verschlüsseln, und dann auf einen ZIP Stream leiten, also in etwas sowas: OutputStream targetStream = new CipherOutputStream(anyOutputStream, cipher); OutputStream zipStream = new ZipOutputStream(targetStreamOutputStream); oder sorum: OutputStream zipStream = new ZipOutputStream(anyOutputStream); OutputStream targetStream = new CipherOutputStream(zipStream, cipher); Zum Thema Verschlüsselung eine generelle Einführung: http://www.galileocomputing.de/openbook/javainsel4/javainsel_24_004.htm