Zitat:

---

Original von Wolfman:
http://www.heise.de/ct-tv/artikel/Hintergrund-Modern-Reisen-830784.html

---

Danke für den Link. Da wird ja nun klar, dass nicht, wie die Werbeseite für RFID suggerieren will, ein RFID-Chip im Handy klebt, sondern das Handy selbst via NFC funkt, was zwar mit RFID-Kommunikation verwandt ist, aber von einem handelsüblichen RFID-Chip in Bezug auf Datenmenge und erweiterbare Protokolle nicht wirklich nachgemacht werden könnte.

Ob man damit die Daten auch auslesen könnte, wenn das Handy kaputt ist, ist fraglich. Momentan bereitet das ja selbst dann Schwierigkeiten, wenn das Handy funktioniert

--
Good coders do not comment. What was hard to write should be hard to read too.

Zitat:

---

Original von Maja:
Ich hätte dann nur gern noch gewusst, was deiner Ansicht nach einem System aus wiederbeschreibaren RFID-Transpondern nebst Schreib- und Lesegeräten funktional noch hinzugefügt werden müsste und weshalb es für Dich so ausgeschlossen erscheint, dass von Flensburg bis Sonthofen untereinander kompatible Systeme Verwendung finden könnten.

---

Zitat:

---

Na ja, und was an einem RFID-Tag an einem Schlüsselbund logischer sein sollte als in einem Handy.

---

Zitat:

---

Das Thema RFID in Handys beschränkt sich funktional nicht auf Bezahlsysteme.

---

Zitat:

---

Original von Maja:
Tatsächlich nicht? Wie anders soll man denn, bitte, Deiner Ansicht nach folgende Anmerkung von mk verstehen?
http://www.amiga-news.de/forum/thread.php?id=32241&BoardID=5#329388

Zitat:

---

Original von mk:
Schon mal daran gedacht, das zum Beispiel Handyakkus im ungünstigsten Moment (Ein/Ausbuchen, "Fahrschein" Kontrolle) leer sein könnten?

---

---

Zitat:

---

Was hat das damit zu tun, dass Du offenbar meinst, einen RFID-Tag als Fahrscheinersatz in einem Handy sei für Dich nutlos, solange das Handy funktioniert?

---

Zitat:

---

Kein Verkehrsbetrieb rüstet Handys mit RFID nach, vielmehr sollen Handys mit RFID ausgegeben werden (siehe Wolfman). Diese RFID-Tags und die verwendeten Lese- und Schreibgeräte werden wohl kaum etwas anderes sein als handelsübliche Ware.

---

Zitat:

---

Und was die Kompatibilität betrifft: Ein Ticket des Hamburger ÖPNV war noch nie mit dem Berliner oder Müncher ÖPNV kompatibel. Das schließt jedoch nicht aus, dass RFID als Fahrkartenersatz flächendeckend funktionieren kann, wenn überall kompatible RFID-Systeme verwendet werden (gleiche Modulation).

---

Zitat:

---

Original von DrNOP:
Es gibt aber Parkhäuser, die eine elektronsich lesbare "Münze" als Parkschein ausgeben. Die wirfst du wie gewohnt in die Ausfahrschranke, wo sie aber nicht weggeworfen ist, sondern von der Einfahrschranke wieder ausgegeben wird. Ob das RFID ist? Keine Ahnung.

---

Zitat:

---

Hab' ich nicht auch ein Bild im Personalausweis? Und der soll ja auch eindeutig sein. Warum nicht den verwenden als Ticket?

---

Zitat:

---

http://www.tagesschau.de/ausland/landminen102.html

Obama will Konvention nicht unterzeichnen

USA halten an Landminen-Politik fest

Die USA werden auch unter der Regierung von Präsident Barack Obama nicht dem internationalen Abkommen zur Ächtung von Landminen beitreten. Man habe die bisherige Haltung überdacht und beschlossen, an der Landminen-Politik der Bush-Regierung festzuhalten, sagte der Sprecher des US-Außenministeriums, Ian Kelly, in Washington.

---

Zitat:

---

Original von Maja:
RFID-Transponder werden entweder induktiv vom Lesegerät mit Strom versorgt (passive Tags) oder verfügen über eine eigene Batterie (aktive Tags und active Backscattering). Leere Handy-Akkus dürften somit kein Thema sein.

---

Zitat:

---

Original von Maja:
RFID ist nicht nur lesbar, sondern kann auch wiederbeschrieben werden. Handys sind weit verbreitet und wer ein Handy hat, trägt es in der Regel ständig mit sich herum. Um den RFID-Tag in einem Handy zu nutzen, muss das Handy nicht mal eingeschaltet sein.

---

Zitat:

---

Zitat:

---

Wenn das Handy funktioniert, brauche ich den RFID-Chip nicht,

---

Wie meinen?

---

Zitat:

---

"Dumm" ist das im Kontext nur, solange es noch Handys ohne RFID gibt. Denn solange wird man auch noch Tickets produzieren und ausgegeben müsssen. Wäre aber nicht die erste Übergangslösung bei der Einführung einer neuen Technik.

---

Zitat:

---

Original von mk:
Schon mal daran gedacht, das zum Beispiel Handyakkus im ungünstigsten Moment (Ein/Ausbuchen, "Fahrschein" Kontrolle) leer sein könnten?

---

Zitat:

---

Der RFID dient aber zum Ein /Ausbuchen und Kontrollreserve. Ist der "Fahrschein" (codiertes Bild im Handy) bei einer Fahrscheinkontrolle nicht lesbar (Akku leer usw.), erfolgt die (dann nachträgliche) Kontrolle der berechtigten Nutzung des Verkehrsmittels (sprich der Bezahlung) auch über die RFID. Einen RFID Chip (mit Antenne) könnte man prinzipiell auch nachträglich auf jeden Handy auf/einkleben.

---

Zitat:

---

Original von Archeon:
Man kann als Handybesitzer sein Handy an einem Scanner entwerten lassen.

---

Zitat:

---

Vorrausgesetzt dieses Handy ist mit einem RFID Chip ausgestattet. Bei den neuen Handy ist ein RFID Chip bereits eingebaut, bei den alten kann man diesen Nachrüsten lassen.

---

Zitat:

---

Original von AGSzabo:

Zitat:

---

Soll das Hauptprogramm nichts tun außer auf den Subprozess warten, das heißt soll das GUI des Hauptprogramms blockiert sein, oder nicht?

---

ich sehe mir beide varianten an und entscheide mich.

---

Zitat:

---

Original von AGSzabo:
Allerdings, wenn die maus den rand des gadgets verlässt oder der knopf an den rand kommt, wird der neue angriffspunkt richtung rand des knobs und darüber hinaus verschoben, der sollte aber auch dann gleich bleiben, aus kosmetischen- und gewohnheitsgründen.

---

Zitat:

---

Original von AGSzabo:
der haupttask ist der welcher als erstes gestartet wurde. der managt auch das gui, also wenn das programm beschäftigt ist, geht das gui nicht. wenn ich will, dass der haupttask erst aus der filerequester-funktion zurück kehrt wenn ok oder cancel geclickt wird, geht derweil das gui nicht. daher braucht der requester sein eigenes gui und dazu einen eigenen prozess.

---

Zitat:

---

Original von Thore:
...
Oder man segmentiert den Chip RAM und tagged die eine Hälfte als Fast.
Sauber ist beides nicht

---

Zitat:

---

Original von Thore:
Unbestritten der beste BASIC Dialekt ever, jedoch das einzige Programm auf diesen Disks das mit Kick > 2.x Probleme macht....

---

Zitat:

---

Original von AGSzabo:
wenn ich will, dass DoMethod(selectfile) erst zurück kommt wenn ein file ausgewählt wurde (wie asl), geht da zwischendurch das gui des parent prozesses nicht und kann auch nicht vom unterprozess genutzt werden, sondern letzterer braucht einen eigenen prozess der sein eigenes gui (den filrequester) öffnet und durch die masterlibrary handhabt. das parent-gui bleibt derweil taub, man könnte den mauszeiger der parent windows auf DIE UHR setzen.

---

Zitat:

---

Original von DrNOP:
Als erstes die Mausposition besorgen und feststellen, wo der Zeiger relativ zum Knopf liegt. Und bei allen Verschiebeaktionen würde ich dann den Abstand des Mauszeigers vom linken Knopfrand abziehen. Dann sollte doch der Knopf wieder an dem zuerst gegriffenen Punkt unter der Maus zu liegen kommen - sofern jetzt nicht ich einen Denkfehler gemacht habe.

---

Zitat:

---

Original von Thore:
Optimal wär beides *g*
Aber ich sollte erstmal wissen was dieser Thread denn konkret macht und wie er eingebunden wird, also ob er explizit im Java Code hinterlegt werden muss oder von der VM erzeugt wird.

---

Java code:

---

static java.io.FileWriter LOG_FILE;

static
{
  try
  {
    LOG_FILE = new java.io.FileWriter("application.log", true);
    LOG_FILE.write("Application Started Logging "+new java.util.Date()+"n");
  } catch(java.io.IOException e)
  {
    throw new ExceptionInInitializerError(e);
  }
  Runtime.getRuntime().addShutdownHook(new Thread("Finish Logging")
  {
    public void run()
    {
      finishLogging();
    }
  });
}

static void finishLogging()
{
  try
  {
    LOG_FILE.write("Application Exit "+new java.util.Date()+"n");
    LOG_FILE.close();
  } catch(java.io.IOException e) {}
}

---

Zitat:

---

Original von Thore:
Ja es geht um JAmiga. Da ich in "Java Intern" nicht soo fit bin, bin ich für Hilfe dankbar =)
Vielleicht kannst du ein Beispiel posten?

---

Zitat:

---

Original von AGSzabo:
garantiert nicht, denn der parent prozess macht nach dem absenden der 'startup"-message nie und nichts anderes als auf diese message zu warten dass sie zurück kommt.

---

Zitat:

---

Original von Bogomil76:
Anscheinend haben die ja genauso sich die Anschlussdaten vom Provider geholt.
Nur weil Provider XY dies aber nicht eidesstattlich versichert hat, wirkt die eidesstattliche Versicherung der Beklagten gewichtiger.

---

Zitat:

---

Original von AGSzabo:
aber die rückwantwort, kann die an den process-port des parent-prozesses gehen (der schon dos funktionenen aufgerufen hat) oder muss ich extra einen replyport einrichten?

---

Zitat:

---

eigentlich brauche ich keine antwort, muss nur warten bis der prozess fertig ist ... also reicht ein signal?

---

Zitat:

---

Original von RhoSigma:
Klar kann die Antwort an den parent gehen, und wenn mehrere Msg dort
ankommen (z.B. von DOS-Operationen), dann must du nur deine Msg entsprechend identifizieren (z.B. mit ID versehen).

---

Zitat:

---

Original von AGSzabo:
@RhoSigma:
ich dachte, der neue prozess darf die message selber freigeben? ich weis ja was ich tue weil alles meins ist.

---

Zitat:

---

Original von Thore:
Hmm das Problem ist, daß eine externe Lib die GUI Elemente erstellt, und wenn ich das Hauptprogramm durch Ctrl-C abbreche soll er alles schließen.

---

Zitat:

---

Original von AGSzabo:
ok, zu dem schluss bin ich auch gekommen. allerdings sollte ich zum empfang der antwort einen eigenen temporären port anlegen weil der port den ich schon habe ja die intuimessages der fenster erhält und da würde was durcheinander kommen.

---

Zitat:

---

kann ein task (nicht ein prozess!) funktionen der doslibrary benutzen, also zB ein verzeichnis einlesen? gedacht für asynchrones laden des verzeichnisinhaltes, so dass das gui clickbar bleibt.

---