Moin,
also, ich erkläre mal kurz was ich mir so gedacht bzw. was ich gemacht habe (leider sitze ich gerade im Büro und habe weder die API-Doku noch meine Programme zur Verfügung, meine Erinnerung an das ganze ist auch schon leicht getrübt, so dass die Erklärungen etwas unscharf sind):
Die API Funktion zum Senden von Tastaturereignissen lässt sich missbrauchen, um statt eines normalen Tastaturcodes zwei beliebige Bytes (die sich dann natürlich nicht mit echten Tasten beißen dürfen) zu senden.
Auf die Art können TAPs also prinzipiell schon mal (sehr rudimentäre, da parameterlose) RPCs anbieten, d. h. eine Anwendung könnte auf eine bestimmte (virtuelle) Taste hin mit dem Ausführen einer bestimmten Funktion antworten, diese virtuelle Taste könnte eine andere Anwendung abschicken. Zwei Beispiele:
- Aus Filer heraus könnte auf die oben beschriebene einfache Weise der (verzeichnisübergreifende) Papierkorb-Dialog der Improbox aufgerufen werden, eine Funktionalität, die ich schon lange in Filer vermisse und die in Improbox ja auch schon realisiert ist (und deshalb IMHO nicht noch einmal in Filer nachprogrammiert werden müsste). War nur ein Beispiel, ich weiß, mit der Filer-DB wird das dann auch möglich sein.
- Ich habe diesen Weg benutzt, um mir eine Anwendung TAPmenu zu schreiben, die über eine Menuauswahl andere Anwendungen aktiviert.
Hintergrund: da mir langsam die freien Tasten für die TAPs ausgingen und ich auch die Originalfunktionen von Subtitle etc. behalten wollte (in der Hoffnung, das ich irgendwann mal auf eine Sendung mit solchen stoße ;-), habe ich einfach in der INI von z. B. MediaManager als Aktivierungstaste z. B. den Code 11111 eingetragen und mein TAPmenu bei entsprechender Menuauswahl diese 11111 versenden lassen. MediaManager erkennt diese Taste brav wie eine normale und öffnet den entsprechenden Bildschirm.
Zwei Byte (die noch nicht mal komplett zur Verfügung stehen, da ja bestimmte Codes für die echten Tasten reserviert sind) sind allerdings relativ wenig, um Informationen auszutauschen. Also habe ich versucht, ein paar Funktionen drumherumzustricken, so dass der virtuelle Tastaturcode einen Pointer auf einen typisierten Speicherbereich darstellt. Da ein Pointer im Topf aber 4 Bytes lang ist, bedarf es zwei aufeinanderfolgender Aufrufe von TAP_SendKey (oder so ähnlich), um den Pointer in zwei Häppchen zu übertragen. Auf der Gegenseite muss dieser Pointer dann wieder zusammengebastelt werden. Das ganze ist also schon etwas komplizierter, weswegen ich das (für den API-Nutzer transparent) in zwei Funktionen gekapselt habe.
Prinzipiell klappte das auch ganz gut, wie die ersten Versuche zeigten, aber das Gelingen der Datenübertragung war unter anderem davon abhängig, wie die gemeinsam genutzten Informationen alloziert wurden, sprich das ganze war noch recht unstabil bzw. klappte nur in bestimmten Kontexten.
Da ich dann nicht den Eindruck hatte, dass das ganze überhaupt je zur Anwendung käme, habe ich meinem Forschungsdrang auch nicht weiter nachgegeben.
Sinnvoll fände ich allerdings eine TAP2TAP-Kommunikation nach wie vor, es müsste nur durch die entsprechenden Anwendungen unterstützt werden.
Mit freundlichen Grüßen
asrael
PS: Mein Ansatz müsste eigentlich (mit den gerade beschriebenen Einschränkungen) auf jeder TOPF-Hardware funktionieren, jedenfalls solange wie die API die übersendeten KeyEvents nicht auf gültige Keycodes überprüft.
Ich sagte ja schon, dass ich nur so aus dem Gedächtnis poste.
: Die F/W-Routine ist nicht brutal.
ops: aber das werde ich nachholen. Warum willst Du so viel per Event übertragen? Ich würde das alles in die struct packen und nur einen Pointer dahin per Event versenden.
Guckst Du 