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:
package UDP;
import java.io.IOException;
import java.net.*;
import java.util.logging.Level;
import java.util.logging.Logger;
public class Receiver extends Thread implements Runnable, ReceiverInterface
{
private InetAddress receiveIp;
public DatagramSocket socket;
public DatagramPacket packet;
private byte[] buffer;
private String message;
public boolean status = true;
ReceiverInterface receiverInterface;
public Receiver(InetAddress receiveIp, ReceiverInterface receiverInterface)
{
message = "";
this.receiverInterface = receiverInterface;
this.receiveIp = receiveIp;
run();
}
public void run()
{
while (status)
{
buffer = new byte[4098];
packet = new DatagramPacket(buffer, buffer.length);
try
{
socket = new DatagramSocket(4711);
try
{
socket.receive(packet);
logMessage(new String(buffer), receiveIp);
socket.close();
}
catch (IOException ex)
{
System.out.println(ex);
}
}
catch (SocketException ex)
{
System.out.println(ex);
}
}
interrupt();
}
public void logMessage(String message, InetAddress receiveIp)
{
receiverInterface.logMessage(message, receiveIp);
}
}
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.
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 von Engel der Furcht
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 von Engel der Furcht
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 von Engel der Furcht
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 von Engel der Furcht
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.
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?
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.
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.
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.
Das schönste was ich je mit C verzapft hatte war eine Rekursion ohne Rekursionsanker, Prozesse quasi-rekursiv zu forken und innerhalb einer Rekursion nach dem Allozieren von Speicher das Freigeben zu vergessen .
Alles schöne Sachen die man erst zur Programmzeit merkt, weil die Speicher- und Prozessorauslastung recht schnell in die Höhe geht.
Was ich auch immer wieder lustig finde, ist wenn man in C/C++ mit Pointern in Arrays rum stochert, statt über den Index zu zu greifen.
Das schrägste was ich mal in einem Quellcode gesehen habe war folgendes:
... (irgendein Code) ...
if(1 == 1)
return();
... (irgendein Code, der aber nie ausgeführt wird) ...
Programmiersprache war da Java, einfach schlechter Programmierstil. Was man nicht braucht, sollte man auskommentieren oder gleich entfernen, sonst wird das Kompilat bei schlechten Compilern größer.
Ich hab mir die Tage das Retro BASIC Sonderheft zugelegt. Ich bin zwar totaler ein programmier Analphabet, aber ich habe so eben mein erstes Listing in meinen MSX getippt^^
Leider endete der 2. Screen in einer Fehlermeldung, was mich veranlasst hat meinen Code mit dem aus dem Heft und dem vom Ursprungsposting zu vergleichen. Und siehe da! Ich hab meinen ersten Code debuggt*g der Fehler lag darin, dass wo bei mir und im Heft
B:WITH32:
steht,
B:WIDTH32:
hätte stehen müssen.
Jedenfalls bin ich neugierig wie das Ergebniss sein wird wenn ich korrigierte Fassung eingebe.
Ziel des ganzen ist übrigens ein Spiel bei dem man am oberen Bildschirmrand seine Spielfigur nach links und rechts steuern kann und den von unten etgegenscrollenden Sternen ausweichen muss. Je länger man durchhält desto höher ist die Punktzahl und es ist möglich die Spielfeldbreite einzustellen.
Für die Neugierigen, hier ist der Originalpost http://www.msx.org/forum/development...msx-basic-game
Schon Schade, dass das alles vor meiner Zeit war. Ich hätt da bestimmt Spaß dran gehabt^^
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.
@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?
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.
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.
...
Es wird keinen blink-Präfix geben. Blink wird neue Features über versteckte Konfigurationsparameter stellen. Du mußt also in deinem Browser einschalten, daß er Feature XYZ verwenden soll. Sobald die Spezifikation für das Feature von W3C als fertig definiert wird und Blink diese Spezifikation voll unterstützt, wird das Feature dann standardmäßig aktiviert. (Zum Zeitpunkt des Forks bereits existierende webkit-Angaben werden allerdings weiter unterstützt.)
Mit anderen Worten: Wir kommen endlich aus der aktuellen Situation raus, wo alle möglichen Leute in ihren Webseiten Kram verwenden, der noch gar nicht fertig spezifiziert ist, aber dank webkit- in Chrome schon mehr oder weniger läuft. Bonuspunkte, wenn die finale Syntax dann abweicht. Doppelte Bonuspunkte, wenn man so geil war und für keine andere Engine Präfixe angegeben hat, weil zu dem Zeizpunkt kein anderer Browser das Feature hatte. Vendor prefixes waren für ihre Zeit eine gute Idee, aber Webkititis hat dem Web als Plattform doch eher geschadet.
Jo wie gesagt 'vllt'. Hab jetzt nicht so genau da rein gelesen. Zumal mir das eigentlich auch egal ist so lange das Feature funktioniert. Ist auch kein Problem das als Entwickler zu ändern finde ich. Das ist ne Sachen von einige Minuten. Ich hab nichts dagegen wenn Browser einheitlich namen für ihre Features haben. Dann hat man nicht mehr diese dummen abfragen in denen Vendor-Präfixe abfragt