bei Key Long (flag=l) ohne Screen-Aufruf wird im Anschluss immer noch Key Short (flag=b) ausgeführt

  • Hallo


    Reichi - ist das ein Bug in e2 ?


    Ich hatte das Problem hier schon mal angesprochen, wo aber vermutlich keiner wusste, was ich meinte :winking_face:

    Wie Tasteneingaben der FB zurücksetzen ? - Developer - Enigma 2 - Dreamboard (dreambox.de)


    Nun ist das Problem (durch Meldung eines anderen Entwicklers) wieder angesprochen worden, woraufhin ich dazu jetzt mal ein Test-Plugin erstellt habe.


    Bei grün-Lang wird das Auslösen zur Kontrolle in ein Label geschrieben.

    Nur wird dann beim Loslassen der Taste sofort zusätzlich immer noch das grün-Kurz ausgelöst.


    Bei gelb-Lang führe ich im Anschluss als Workaround noch das hier aus, wodurch gelb-Kurz dann nicht mehr ausgeführt wird:

    self["actions"].p.keyPressed("",0,0) - keine Ahnung, ob das negative Auswirkungen haben könnte


    Bei blau-Lang wird eine MessageBox eingeblendet, wodurch das blau-Kurz danach auch nicht ausgeführt wird.



    Nun ist die Frage, warum bei Screen-losen Tasten-Aktionen, ein langer Tastendruck im Anschluss immer noch den kurzen Tastendruck auslöst :thinking_face:

  • Ich wollte nur sagen, dass das Verhalten genauso wie erwartet ist. Es steht im Kommentar, dass nach dem Loslassen immer ein b kommt.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

    • Offizieller Beitrag

    Naja b steht für break.. also das ist ein break code, der schon im Treiber generiert wird.


    Break kommt bei jedem loslassen der Taste... immer.


    Wenn du also Folge eines "long" keypress einen neuen screen öffnest.. oder als folge eines "make" codes... dann ist danach ein neuer Screen offen.. deshalb geht dann halt der "break" code verloren.


    Aber solange ein Screen offen ist wird immer das break kommen. Ich wüsste auch nicht wie man das verhindern will.. weil das halt total verschiedene keycodes sind die da aus dem Treiber / kernel eventdevice kommen.


    cu

  • Ok, so hab ich mir das auch schon gedacht, wenn sich ein neuer Screen öffnet, dass dann die Tastenevents irgendwie auf 0 resetet werden und damit keine nachfolgenden Events gefeuert werden.


    Vielleicht gibt es ja sogar Anwendungsvarianten, wo das anschließende Ausführen der weiteren Events im gleichen Screen gewünscht ist :thinking_face:

    Denn wenn ich "m", "l" und "b" einbinde, werden alle drei ausgelöst, wenn man die Taste lang drückt und dann loslässt.


    Reichi oder Ghost

    Könnte man da evtl. noch ein zusätzliches flag="...a" für abort einfügen?

    Dann könnte man das Auslösen des Loslassens nach Langer Taste mit "la" unterbinden. :winking_face:

    Oder mit "ma" das anschließende Auslösen von "l" nach "m", wenn man die Taste noch länger festhält.

    Dann müsste e2 nach einem "...a" eben nur das Ganze mit einer Neutralisation beenden.


    Wenn das nicht geht, muss man das eben mit dem self["actions"].p.keyPressed("",0,0) umgehen, wobei ich nicht so recht weiß, ob das negative Auswirkungen haben könnte :thinking_face:

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

    3 Mal editiert, zuletzt von Sven H ()

    • Offizieller Beitrag

    Hmm das ist im core schwierig zu handlen... weil dann müsste der code sich ja merken, ob eine make/long action die vorher lief einen passenden handler hatte.. und der handler mit einem valid return code beendet wurde...


    Aber dein keyPressed ist ein funktionierender Workaround. Dieser funktioniert weil dann innerhalb des Handlers für das long ja ein neuer Tastendruck simuliert wird. Dieser simulierte Tastendruck überschreibt dann den vorherigen "make" code. Und ein long oder break wird immer nur ausgeführt, wenn der vorherige Tastendruck von der selben Taste kam und ein make war. Das sollte theoretisch keine Nebenwirkungen haben.

  • Ok, Danke. :winking_face:

    Dann kann man das tatsächlich als Workaraound nutzen.


    Ich glaube, man müsste noch ein self["actions"].p.keyPressed("",0,1) hinterhersenden, da ich im LostKeys-Plugin schon gemerkt hatte, dass man jede Tastensimulation auch wieder ordentlich beenden muss, weil sich e2 sonst irgendwann verhaspelt, wenn das nicht sauber gemacht wird :winking_face:


    So sollte es dann gehen (mit keypress und release key für KEY_RESERVED:

    self["actions"].p.keyPressed("",0,0)

    self["actions"].p.keyPressed("",0,1)


    Wofür steht denn der 1. String-Parameter bei dem Aufruf ?

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

    • Offizieller Beitrag

    Der erste Parameter wäre der devicename also wenn man in der actionmap "<device name="dreambox advanced remote control (native)"> .... oder sowas verwendet..

    Hmm das senden des break sollte in dem Fall eigentlich egal sein, weil beim nächsten Tastendruck eigentlich wieder ein make kommt, was die "state machine" da wieder zurücksetzt.