Suchergebnisse

Moin Moin! Falls das hier auch unter die NDA fällt, sagt es mir bitte... Ich versuche mich grade endgültich für das bezahlte Coden anzumelden. Nun steht in iTunes Connect: Diese Informationen können nachträglich nicht geändert werden. Und es werden komplizierte Informationen abgefragt. Hat das schon einer hinter sich gebracht? Was muss ich hierzu eintragen: - Account Name (Need exact account name): - Account Type: - Branch/Branch ID: - Bank Swift Code: - Sort Code (UK) / SIC (SZ): Und was muss i…

Der Thread wird nach beenden der run()-Methode gelöscht.

Die Methode invokeLater führt den Code in der void run() Methode später auf dem Haupt-Thread von Swing aus. Der Haupt-Thread von Swing ist der einzige, der etwas an der Oberfläche verändern darf. Du musst das also so strukturieren, dass du die Hauptarbeit in einem eigenen Thread machst und die Aktualisierungen der Oberfläche in einer invokeLater-run()-Methode. Erklärung hier: SwingUtilities#invokeLater(java.lang.Runnable) Und "Java ist auch eine Insel" ist bei sowas auch immer sehr hilfreich: Sw…

Mir ist grade noch was eingefallen. Wenn du nur anzeigen willst dass du arbeitest und du keine Rückmeldung geben möchtest wie viel fertig ist (also deine Progressbar endlos laufen soll, bis du fertig bist) kannst du auch bei der Progressbar: Quellcode (1 Zeile) setzen. Und wenn du fertig bist setzt du: Quellcode (3 Zeilen)

Also dein Code erzeugt in einer Schleife so schnell es geht neue anonyme Objekte vom Interface Runnable. Das es da zu OoMem-Exceptions kommt ist ja klar. Deine ursprüngliche Schleife ist aber ebenso humbug. Du kannst ja nicht in einer Endlos-Schleife nur die Progressbar aktualisieren. Wofür soll das sein? Dein Code macht was mit dem Bild. Dies machst du in einem neuen Thread. Also so: Quellcode (20 Zeilen) Innerhalb deines Threads rufst du also invokeLater auf, um die Swing-Oberfläche zu aktuali…

Zitat: „Original von mattik Grundsätzlich ist Deine Idee, das in einem separaten Thread zu machen, schon gut. Aber mit der Schleife danach blockierst Du den Swing Thread mit busy waiting - die Kontrolle in dem Thread geht erst zu Swing zurück, wenn der Ladethread beendet ist. Deshalb kann Swing seine Warteschlange mit Events und Updates nicht abarbeiten. “ Genau, deswegen Thread.yield(); Zitat: „Original von mattik Stimmt - invokeLater erwartet nicht direkt eine Methode oder Funktion. Sowas wäre…

Zitat: „Original von mad-boy mmm... das verstehe ich nicht so ganz! Ich dachte genau das hätte ich mit meinem Aufruf umgangen? Ich rufe ja mit new Thread(new gettingImage())).start(); einen neuen Thread auf. In diesem Thread werden die Berechnungen gemacht. Und unter dem Aufruf des Threads (also im alten Thread, parallel laufen?) rufe ich eine endlosschleife auf, die immer die GUI updatet. Dann wird doch die GUI im Swing Thread geupdatet oder nicht? Und das theoretisch doch parallel zu meiner Be…

Also die Römer würde daraus logischerweise: XI machen.

Ein paar Punkte die in Netbeans besser sind: - Alle Plugins sind entweder schon Teil von Netbeans oder können einfach runtergeladen werden (ohne 3rd Party webseiten). - Netbeans ist Pure-Java und verwendet nicht dieses bekloppte SWT - Finde viele Plugins einfach besser als bei Eclipse: - Besserer Editor für Mobile (JavaME) Anwendungen - Besserer Editor für Web-Anwendungen - Besserer Editor für Swing GUIs Zumindest früher (hat sich mittlerweile gebessert, glaube ich) gab es z.B. keinen HTML-Edito…

Ich dachte es geht hier um GUI Entwicklung. Nicht um das nachahmen von Flash-Applikationen. Ich finde die Idee hinter Aerith auch gut und der Entwickler der das gebaut hat (Romain Guy) kann auch viel in Sachen Java und Grafik und so... aber eine gute GUI muss nicht grafisch total aufgepeppt sein, sondern funktional und ergonomisch. Außerdem verstehe ich eure Kommentare nicht ganz. Ihr wisst schon, dass Aerith auch in Java gecodet ist? Meiner Meinung nach sind "schöne GUIs" funktionale, ergonomis…

Also gute GUIs zu basteln ist nicht Sache der Programmiersprache. Leider haben sehr viele kostenlose Programme eine grauenhafte GUI (das galt z.B. lange Zeit auch für OpenOffice). Selbst auf dem iPhone habe ich schon Programme gesehen die wirklich grauenvolle GUIs hatten. Obwohl die API und die Controls sehr geil sind. Ich kann JGoodies (jgoodies.com/) empfehlen. Der Karsten Lentzsch hat's drauf und vermittelt sein wissen sehr gut. Er hat z.B. eine Beispielanwendung an der er den Weg von einer g…

Zu Eclipse gibt es die Europa-Variante, die enthält schon ein paar nette Plugins. Aber ich würde für die Java-Entwicklung von Eclipse abraten und Netbeans 6.1 einsetzen. Da ist in der Standardversion schon alles bei und zusätzliche Plugins lassen sich sehr schön direkt aus dem Plugin-Manager installieren (mit einer kurzen Beschreibung, etc.). Ich entwickle schon länger in Java und finde Netbeans um LÄNGEN besser als Eclipse.

Diese Diskussion ist total bekloppt. Daher misch ich mich auch mal ein Der einzige Grund dafür, dass es kein angepasstes AppKit gibt sondern ein neues UIKit ist: Das UIKit ist komplett leichtgewichtig ohne Altlasten von AppKit. Fertig. Auch wenn das iPhone nen kleiner Mac ist, ist es doch begrenzt an Resourcen. Also macht es durchaus Sinn dafür nen eigenen UI-Layer zu entwickeln. Außerdem: stell dir vor, du hast einen AppKit, der voller spaghetti Code ist. Was würdest du da bei solch einem Proje…

Hallo! Die Idee finde ich nicht schlecht. Wenn ich demnächst auch in Berlin wohne, hätte ich auch Interesse an solch einem Treffen. Viele Grüße, Christian

Zitat: „Original von seb2 Zitat: „Original von spekul Die Sache mit dem NSXMLParser und NSXMLDocument habe ich ebenfalls festgestellt und bin exakt ueber den gleichen Abschnitt wie seb2 in der Dokumentation gestolpert. Ich kann mir nicht vorstellen, dass das so bleiben soll. Zumindest hoffe ich es.“ Ich habe festgestellt daß das relativ undramatisch ist. XPath ist mein Freund und ich komme damit sogar fast schneller ans Ziel als mit dem ganzen NSXML*. Alles, was ich damit machen wollte, funktion…