TMSCommander

[Happy]

[quote=""deangelj""]
As for covering the TAPs menu, when those TAPs display their menu do they exit normal state? If so then I would imagine that Main State would not be normal? Unless I misunderstand how that works, which is quite likely.
[/quote]
Hi John,

yes, all those TAPs exit normal state. But IMHO this won't change the main state.
Only the substate changes
In my TAPs I check like this:

Code: Alles auswählen

TAP_GetState( &mainState, &subState );
if ((mainState != STATE_Normal) || (subState != SUBSTATE_Normal))
            return param1;

I have got one more question ?
Is the sequence in TMSCommander's list also the sequence in which TAPs process key events. So does the first TAP in the list process a key first and the last in the list is last?

Regards,
Till

[Indy]

[quote=""Happy""]Hi John,

yes, all those TAPs exit normal state. But IMHO this won't change the main state.
Only the substate changes
[/quote]
There is a STATE_Tap. Isn't the main state changed to this when a TAP executes a TAP_ExitNormal? (I can't check at the moment)

[quote=""Happy""]
I have got one more question ?
Is the sequence in TMSCommander's list also the sequence in which TAPs process key events. So does the first TAP in the list process a key first and the last in the list is last?
[/quote]

I can't answer for John but IMHO a TMSCommander enabled tap should not react on any key events during normal state. It should only react when TMSCommander activates it.

[TV-Junkie]

[quote=""FireBird""]Schon seit Ewigkeiten. [/quote]
yepp, funktioniert
Aber, so wie das Einstiegsbild von John sieht das bei mir nicht aus, es fehlen diese Warnhinweise und der grüne Pfeil.
Und (ich weiss, ist noch nicht so ganz Marktreif das Tap) ich dachte, es würden sich Taps verschieben lassen, so wie beim Tap-commander.
Allerdings liesst der TMScommander wohl das Tap selber aus, denn die Bezeichnung zur Startreihenfolge werden nicht angezeigt, wie z.B. 01_NiceDisplay.
Hier steht nur NiceDisplay
Und sorry, das ich hier in deutsch mitschreibe, mein Englisch ist nicht zu ertragen

[Happy]

[quote=""Indy""]There is a STATE_Tap. Isn't the main state changed to this when a TAP executes a TAP_ExitNormal? (I can't check at the moment)
[/quote]
I can't check either, as I'm at work. I just rember that only checking the main state is not sufficient.
[quote=""Indy""]
I can't answer for John but IMHO a TMSCommander enabled tap should not react on any key events during normal state. It should only react when TMSCommander activates it.[/quote]

My question was not whether a TAP reacts on the key, but which TAP's eventhandler is called first, and if this sequence is the same as the list in TMSCommander.

My problem yesterday was, that I started TMSCommander manually. So it was startet last. However it was first in the list and got the exit key before other TAPs that had der OSD shown.
I think the reason for this is that some TAPs in Autostart are not TSR. This would be the same behaviour as on the TF5K.
If I know in which order TAPs a receiving the key events that will help to identify problems.

Regards,
Till

[FireBird]

[quote=""TV-Junkie""]Aber, so wie das Einstiegsbild von John sieht das bei mir nicht aus, es fehlen diese Warnhinweise und der grüne Pfeil.[/quote]
Die wurden wieder entfernt und dafür läßt sich ein TAP, das nicht TMSCDR-kompatibel ist, nicht auswählen.

Und (ich weiss, ist noch nicht so ganz Marktreif das Tap) ich dachte, es würden sich Taps verschieben lassen, so wie beim Tap-commander.

Das ist beim TMS komplizierter und noch nicht vollständig gelöst.

[FireBird]

[quote=""Happy""]but which TAP's eventhandler is called first, and if this sequence is the same as the list in TMSCommander.[/quote]
The TAPs are shown in the same order as they are in the firmware's TAP list (taptask list). Therefore you see them in the same order as they receive the events.

[Indy]

[quote=""Happy""]
My question was not whether a TAP reacts on the key, but which TAP's eventhandler is called first, and if this sequence is the same as the list in TMSCommander.
[/quote]

OK now I understand .
Isn't that part of the OS to handle in what order the TAPs get the key events? I would be very worried if a TAP could change that order... That would mean a TAP could prevent my TAP from receiving key events at all.

Edit: Has been answered by FB while I was typing this

[FireBird]

[quote=""Indy""]That would mean a TAP could prevent my TAP from receiving key events at all. [/quote]
Not at this point, but it is possible to redirect the pointer to the TAP_EventHandler to a dummy handler so that a TAP does not receive any events any more. The SmartCut TAP uses that approach because it creates a lot of key events which immediately need to be passed to the firmware.

[Happy]

My understanding is that if the 1st TAP in this sequence reacts on i.e the Exit key RKEY_Exit it finishes by returning 0, all TAPs after this one will only receive a key event with 0. They won't see that originally "Exit" has been pressed.
This way the first TAP can prevent others from working correctly.

Regards,
Till

[Indy]

[quote=""Happy""]My understanding is that if the 1st TAP in this sequence reacts on i.e the Exit key RKEY_Exit it finishes by returning 0, all TAPs after this one will only receive a key event with 0. They won't see that originally "Exit" has been pressed.
This way the first TAP can prevent others from working correctly.
[/quote]

Isn't this the way it is already now? I don't know how this event system is designed:
"BROADCAST": Every TAP receives the same message
"DAISY CHAIN": The Event is passed from one TAP to the other until one returns 0
"ROUND ROBIN": The Event is passed to every TAP in the TAPList but a TAP can change the Event by returning a different value


If it is a round robin way TMSCommander could even create a new Key value and pass that to the TAP when it starts. That way the TAP only needs to listen to its special own KEY value to open its menu

[FireBird]

None of the three above. : The event is passed to every TAP in the TAPList until a TAP returns 0. Then the remaining TAPs will receive an event=0 (IDLE). params can't be changed because they are passed by value.

[TV-Junkie]

[quote=""FireBird""]


Das ist beim TMS komplizierter und noch nicht vollständig gelöst.[/quote]
Das verschieben auf dem Bildschirm oder der Taps als solches
Beim zweiteren könnte man die Krücke mit den Zahlen davor verwenden, also 01_xy.tap usw

[FireBird]

Nur leider kann man ein TAP, das läuft, nicht verschieben oder umbenennen (im Gegensatz zum 5k).

[Indy]

[quote=""FireBird""]None of the three above. : The event is passed to every TAP in the TAPList until a TAP returns 0. Then the remaining TAPs will receive an event=0 (IDLE). params can't be changed because they are passed by value.[/quote]

OK almost like my "Daisy Chain" example and that is just like I expected it to be. Nevertheless it still means that a TAP higher in the list can prevent events to be send to the TAPs lower in the list.

[TV-Junkie]

Ja dann anders.
Z.b. so.
eine Kombi aus TMScommander und X-Start.
der TMScommander schreibt nur die ini neu nach dem Verschieben
Und das X-Start beendet sich wieder, wenn der topf alle Taps geladen hat.
Einfach, aber genial, gelle
Ich würde auf jeden fall 2 Taps vorschlagen, also ein Tap zur Bedienung, und ein kleines zum Starten der Taps

[deangelj]

[quote=""Happy""]Hi John,

yes, all those TAPs exit normal state. But IMHO this won't change the main state.
Only the substate changes
In my TAPs I check like this:

Code: Alles auswählen

TAP_GetState( &mainState, &subState );
if ((mainState != STATE_Normal) || (subState != SUBSTATE_Normal))
            return param1;

[/quote]

Hi Till - OK - I'll make the change for 0.5 - but I'll also do some more testing on this. On the 2 taps that I have changed to use TMSCommander this works correctly, ie. I exit normal in my called TAP, show the menu, press exit (this exits my called TAP) and then I press Exit to bring back my TMSCommander list (if required).

But I may have missed something in my testing, and checking the substate causes me no issues so I will add it in.

cheers,
John

[deangelj]

So for 0.5 I will

- add support for stopping TAPs
- check the substate

Anything else? I can send a TMSCommander_Exiting event to all TAPs when someone tries to stop it. I can also respond to a TMSCommander_isAlive event if TAPs want to know if TMSCommander is running, maybe to configure key responses appropriately?

cheers,
John

[FireBird]

I personally don’t need any TMSCommander start/stop events. Following the code I’ve used in ScreenCapture:

Code: Alles auswählen

if (param1 == RKEY_Menu && !HDD_TAP_isRunning(TMSCMDRTAPID))
{
  //display menu
  ...
  return(0);
}

return (param1);

So I don’t care how the user abuses TMSCommander until the hotkey is received.

[deangelj]

Ah yes - thanks! That is a better solution.

cheers,
John

[Happy]

I have now checked what happens, if a tap calls TAP_ExitNormal().

Mainstate stays 0 (STATE_Normal)
Substate then returns 0 (SUBSTATE_MainMenu).

Mainstate only changes, when opening a TMS menu.

Regards,
Till