Ergebnis 1 bis 20 von 385

Thema: IM IN YR LOOP\n VISIBLE FOO\n IM OUTTA YR LOOP - Der Programmierer-Spamthread #2

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1

    Users Awaiting Email Confirmation

    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    So kompliziert ist das gar nicht. Gerade in Sprachen, wie Java oder C# ist das recht einfach einzuhalten. In Sprachen, wie php sieht es schon wieder ein wenig anders aus, ist aber auch möglich.
    Sag also konkret, was du vor hast, und ich könnte dir da auch weiterhelfen.
    Nunja, wie ich gesagt hab: Ich hab eine Klasse (die von Frame erbt), in dieser Klasse wird ein Objekt erzeugt. Dieses Objekt soll in eine TextArea aus der ersten Klasse schreiben.

  2. #2
    Direkt nach TextArea würde ich nicht schreiben, dann wäre die Instanz eines erzeugten Objektes abhängig von deiner Frame-Instanz, und genau das will das Model-View-Controller-Prinzip verhindern.
    Klassen, die die Daten bereitstellen, sollen unabhängig von Klassen sein, die die Anzeige bereitstellen. Angenommen, du erzeugst eine Tabelle und willst sie sowohl in Tabellenform, als auch als Diagramm darstellen. Es wäre dann sehr unklug, wenn die Klasse, die die Tabelle (= Model) erzeugt, abhängig von der jeweiligen View ist.

    Schreib die Methode so, dass sie dir die Informationen liefert, die du benötigst und gib diese Daten als Rückgabewert zurück.
    Dann kannst du mit Hilfe dieser Daten den String zusammenbauen (in deiner Frame-Instanz), der in der TextArea angezeigt werden soll.

  3. #3

    Users Awaiting Email Confirmation

    Ich hab das ganze mit einem Interface gelöst.
    UNd stehe gerade vor einem erneuten Problem:

    Ich hab 'ne Klasse, in der ein Objekt erzeugt wird, das von Thread erbt.
    In diesem Thread wartet ein Socket auf Empfang von Daten.
    Ich kann den Thread nicht schließen/killen/terminieren/whatever.
    Ich kann von der Oberklasse auch nicht auf das Socket zugreifen und es schließen.
    Hier mal mein Programmcode:


    Is das mit dem WindowAdapter eigentlich so richtig, ich kriege immer eine NullpointerException(der receiver existiert doch?)

    Jedenfalls kann ich den Thread nicht schließen und habe irgendwie auch sonst keinen Zugriff auf Attribute etc.
    Ich kann also receiver.socket.close() nicht anwenden und receiver.status kann ich auch nicht auf false setzen.
    receiver.interrupt(), .stop() etc. kann ich auch nicht anwenden.

    Als Test ist Sender/Empfängeraddresse auf Localhost gesetzt. "Senden" und "Empfangen" kann ich wohl und auch die ganze Zeit.

  4. #4
    Zitat Zitat von Engel der Furcht Beitrag anzeigen
    Ich hab das ganze mit einem Interface gelöst.
    Für so ein Problem sind Interfaces nicht gedacht.

    Zitat Zitat von Engel der Furcht Beitrag anzeigen
    UNd stehe gerade vor einem erneuten Problem:

    Ich hab 'ne Klasse, in der ein Objekt erzeugt wird, das von Thread erbt.
    Und hier wäre es nun schlauer, du machst dich mit dem Model-View-Controller-Prinzip vertraut.
    Ein Fenster, dass ein Thread startet und auf UDP-Daten wartet ist ein absolutes No-Go.
    Dies muss der Controller übernehmen und nicht die View, oder möchtest du in jedem Fenster die selben Methoden implementieren?

    IdR wird hierfür ein eigener Thread gestartet, der rein nur fürs Empfangen der Daten zuständig ist. Fenster, die auf empfangene Daten reagieren wollen, registrieren sie sich dann mittels eines Listeners und der Thread gibt dann dem Fenster die nötigen Informationen. Beim Schließen des Fensters muss aber tunlichst darauf geachtet werden, dass sie sie wieder deregistrieren.

    Zitat Zitat von Engel der Furcht Beitrag anzeigen
    In diesem Thread wartet ein Socket auf Empfang von Daten.
    Ich kann den Thread nicht schließen/killen/terminieren/whatever.
    Ich kann von der Oberklasse auch nicht auf das Socket zugreifen und es schließen.
    Threads sind sowieso sehr böse, wenn man nicht weiß, was man da tut. Als Einführung kannst du dir ja mal den Wiki-Artikel über das Philosophenproblem durchlesen.

    Zitat Zitat von Engel der Furcht Beitrag anzeigen
    Is das mit dem WindowAdapter eigentlich so richtig, ich kriege immer eine NullpointerException(der receiver existiert doch?)
    Ich kann das hier nur überfliegen, aber der Thread wird ja auch erstmal gar nicht gestartet.
    Die Methode windowClosing() erzeugst du ja in einer anonymen Unterklasse. Die Unterklasse hat aber einen anderen Namensraum, als deine Oberklasse, und deswegen ist für die Unterklasse reveicer gleich Null. Es gibt nun mehrere Wege:
    • Du benutzt in der Unterklasse ein qualifiziertes this. also anstatt receiver.socket.close(); schreibst du dann UDPTransceiver.this.receiver.socket.close();. Dann weiß die anonyme Unterklasse, dass es auf die umschließende Oberklasse zugreifen soll.
    • Du deklarierst receiver als statisch. Wohlmöglich sogar als final static.


    Zitat Zitat von Engel der Furcht Beitrag anzeigen
    Jedenfalls kann ich den Thread nicht schließen und habe irgendwie auch sonst keinen Zugriff auf Attribute etc.
    Ich kann also receiver.socket.close() nicht anwenden und receiver.status kann ich auch nicht auf false setzen.
    receiver.interrupt(), .stop() etc. kann ich auch nicht anwenden.
    Um überstürzt einfach versuchen, irgendwelche Methoden aufzurufen, solltest du dich einfach mal kontrollieren, ob die Objekte überhaupt existieren. Wenn du eine Null-Pointer-Exception bekommst, dann heißt das schon, dass da schon irgendwas nicht existiert. Hast du dich eigentlich schon mal mit dem Debugger beschäftigt?

    Zitat Zitat von Engel der Furcht Beitrag anzeigen
    Als Test ist Sender/Empfängeraddresse auf Localhost gesetzt. "Senden" und "Empfangen" kann ich wohl und auch die ganze Zeit.
    Das heißt also, du weißt es nicht? Bei Netzwerk-Programmierung ist es immer vom Vorteil, man hat einen Netzwerk-Sniffer ala WireShark zur Hand und schaut sich die Datenpakete an, die verschickt werden.

  5. #5
    Mal ganz doof gefragt ( ich hab mit Java nie groß was gemacht ).

    Was bringt es von Thread zu erben? Tut man das in Java so? Oder ist hier mit "Thread" was anderes gemeint als das was man von C# System.Threading.Thread bzw. C++ boost::thread kennt?

  6. #6
    Zitat Zitat von Corti Beitrag anzeigen
    Mal ganz doof gefragt ( ich hab mit Java nie groß was gemacht ).

    Was bringt es von Thread zu erben? Tut man das in Java so? Oder ist hier mit "Thread" was anderes gemeint als das was man von C# System.Threading.Thread bzw. C++ boost::thread kennt?
    Ja, das tut man so in Java. Die Thread-Klasse implementiert nämlich das Interface Runnable, welche die Methode run() implementiert.

  7. #7
    Ah stimmt, Java hat's ja nicht so mit Funktionszeigern/Delegaten/ähnlichen Konstrukten.

  8. #8
    Delegaten hat Java aber doch o.o Nur nicht nach Definition von C/C++. Man löst das dann halt über Interfaces oder so. Allerdings wünschte ich mir oft eine Methode direkt angeben zu können.

    Man muss btw nicht von einem Thread erben. ein Thread Objekt stellt ein Runnable bereit allerdings kann man auch sein eigenes angeben (etwa im C'Tor). Man muss also nicht immer gleich vererben wenn man nur einen kurzen Task ausführen will.

    @Topic
    Ich arbeite gerade an WebAudio Kram für CrossCode. Ich glaube das ist die Beste Audio API die ich bisher hatte. Für Spiele ist es eben nicht nur wichtig einen Sound abzuspielen oder ein Musikstück (So wie das viele Engines eben tun, also für Spiele), sondern nutzt ein Graphen über den ein Sound/Musikstück bis zum "Destination"-Knoten wandert. dadurch ist es super einfach global volume oder effekte einzubauen. Stellt euch vor ihr habt einen Track der sich mit der Umgebung anpasst. Halt wie bei Zelda. Das ist mer API relativ einfach möglich. Man nimmt einfach die einzelnen Instrumente und spielt alles gleichzeitig ab, dann faded man zwischen den Instrumenten schön hin und her.

  9. #9
    @Web-Audio
    Wird das außerhalb von Chrome schon unterstützt?

  10. #10
    Zitat Zitat von Mivey Beitrag anzeigen
    @Web-Audio
    Wird das außerhalb von Chrome schon unterstützt?
    Das?

  11. #11
    Bei Firefox scheint auch in "naher" Zukunft was zu kommen: https://wiki.mozilla.org/WebAudio_API_Rollout_Status

    Edit: Oh, wobei, Nightly 23 ist ja schon verfügbar

    Geändert von Cepanks (11.05.2013 um 14:30 Uhr)

  12. #12
    Ah das ist doch schon mal gut. Hoffentlich machen dir nicht wieder ihr eigenes Ding wie bei der Gamepad API. Die müssten sie auch mal an den Standard anpassen, dann würde ich das auch in CrossCode einbauen.

  13. #13
    Ja in Safari.

    Ich bin immer dafür die neuen Sachen zu pushen. Es stört mich schon das andere Browser bestimmte Sachen so langsam implementieren aber es ist nur eine Frage der Zeit.

    Edit:
    Bei Firefox ist immer alles geplant xD Aber vllt wollen sie auch erstmal die JavaScript Execution verbessern. Die ist in Chrome imho am Besten.

    @Deamonic
    Mh, eigentlich unterstützt Chrome die volle WebAudio API. Nicht nur "teilweise". Aber es kann auch daran liegen das die ChromeDevs immer noch sagen das es "beta" ist.

    Geändert von R.D. (11.05.2013 um 14:28 Uhr)

  14. #14
    Zitat Zitat von R.D. Beitrag anzeigen
    @Deamonic
    Mh, eigentlich unterstützt Chrome die volle WebAudio API. Nicht nur "teilweise". Aber es kann auch daran liegen das die ChromeDevs immer noch sagen das es "beta" ist.
    Hm, wie wird es in Sachen Kompatibilität aussehen, wenn Chrome von der WebKit-Engine auf die neue Blink-Eninge wechselt?

  15. #15
    Zitat Zitat von Deamonic Beitrag anzeigen
    Hm, wie wird es in Sachen Kompatibilität aussehen, wenn Chrome von der WebKit-Engine auf die neue Blink-Eninge wechselt?
    Bei Blink geht es primär um um das Rendering (von Grafiken). Mit Audio hat das wenig zu tun, Zumal die WebAudio API ein Standard ist. Das ist nichts webkit spezifisches. Für dich als Entwickler bleibt wohl alles gleich. Es wird immer noch den Präfix webkit geben. Vllt markieren sie es auch als deprecated und man soll in Zukunft blink als Präfix verwenden. werden wir ja in den kommen Wochen sehen.

  16. #16
    Mein Fazit zu JavaFX 2.2 (im folgenden auch nur "JavaFX" genannt): Schöne Lösung um sowohl RIAs zu schreiben als auch Desktop-Anwendungen zu schreiben.

    Pro:
    Seit Version 2 ist das normales Java statt eine eigene Scriptsprache.
    Man kann GUIs zusätzlich mit FXML- und CSS-Dateien definieren. Das ist wesentlich angenehmer als GUIs komplett im Quellcode zu schreiben.
    In FXML-Dateien kann man einen Controller angeben, der beim Parsen der FXML-Datei automatisch instantiiert wird. MVC ist somit schon fast build-in.
    Den Zugriff zwischen FXML und Java-Klassen läuft über Annotations beim Controller.
    Lässt sich direkt in AWT/Swing und sogar SWT embedden.
    In JRE 7 Update 6 wurde JavaFX integriert, NetBeans unterstützt JavaFX in neueren Versionen und für Eclipse Indigo/Juno gibt's einen Plugin namens e(fx)clipse.

    Kontra:
    Leider noch nicht Feature-komplett: Schönstes Beispiel ist der HTMLEditor, wo man nur mit etwas rumtricksen Buttons in der Kontroll-Leiste ausblenden kann.
    Das Binding von (nicht statischen, z.B. aus einem POJO kommende) Daten an die Spalten einer Tabelle oder als Inhalt einer Liste ist ohne 3rd-Party-Library noch sehr umständlich.
    Einige Layout-Panes verhalten sich im Zusammenspiel mit z.B. ScrollPanes unerwartet recht merkwürdig.

    Geändert von niR-kun (09.06.2013 um 22:48 Uhr)

  17. #17
    Yeah, High Quality Splatting von Punktwolken in WebGL mehr oder weniger fertig. \o/
    Klicke auf die Grafik für eine größere Ansicht 

Name:	splatting.png 
Hits:	131 
Größe:	128,4 KB 
ID:	18025

  18. #18
    Schonmal so als Vorwarnung: am Wochenende ist Molyjam Deux, ein Gamejam mit aus dem Kontext gerissenen Zitaten von Peter Molyneux als Thema.

    Drüber gestolpert bin ich durch einen Aushang bei uns an der Uni. Da wird wohl das ganze Wochenende über in den Rechnerräumen der Informatikfakultät gemeinsam gebastelt. Ich werd aber wohl wenn überhaupt von daheim aus teilnehmen.

  19. #19
    Du meinst Molydeux, nicht Molyneux.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •