Dokumentation von virtual void cStatus::OsdCurrentItem(const char *Text)

  • In status.h steht:

    Code
      virtual void OsdCurrentItem(const char *Text) {}                                                                                                   
                   // The OSD displays the given single line Text as the current menu item.

    Das ist etwas kurz, ich würde folgendes schreiben:

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Wenn ich das designen würde, würde ich 2 Methoden anbieten. 1.:

    Code
    virtual void OsdItemSelected(int line_number) { }  

    Diese Methode wird nur im oben genannte Fall 1 gerufen. Also wenn eine neue Zeile gewählt wird. Der auf dem OSD gezeigte Text wird nicht geändert.

    Und 2.:

    Code
    virtual void OsdItemChanged(int line_number, const char *Text) { }  

    Wird gerufen, wenn sich der in Zeile line_number dargestellte Text auf dem zur Zeit angezeigten OSD ändert. Also im oben genannten Fall 2a.

    Wenn sich Text auf einem OSD, das gerade gebaut wird, aber noch nicht angezeigt wird, ändert, dann wird keine Methode aufgerufen. Also im oben genannten Fall 2b.


    Anstelle von line_number kann man natürlich auch index schreiben.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Hi,

    Anbei ein Patch. Der Patch stellt

    Code
      virtual void OsdItemSelected(int Index) {}                                                                                                                         
                   // item with Index is selected                                                                                                                        
      virtual void OsdItemChanged(const char *Text) {}                                                                                                                   
                   // currently selected item is changed                                                                                                                 

    bereit.

    Allerdings wird OsdItemChanged auch gerufen, wenn das Item zur Zeit nicht dargestellt wird.

    Ich hatte überlegt, virtual cOsdItem->Set() in einem Parameter mitzugeben, ob ein derzeit dargestellter Text geändert wird. Das ist aber vermutlich incompatibel zu Plugins, da die Methode virtual ist.

    Hat jemand eine Idee, wie das gelöste werden kann?

  • Wenn OsdItemSelected als Hint 'item with Index is selected' hat, könnte man das nicht kürzer ItemIndex nennen ?

    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • Also OsdItemSelected_2.txt geht mir irgendwie zu weit. Vielleicht sollten wir uns nochmal zurücklehnen und klären, was das eigentliche Problem hier ist.

    In cOsdMenu::Display() wird cStatus::MsgOsdItem() für alle Items im Menu aufgerufen, mit dem jeweiligen Index und (neuerdings) mit der Info, ob sie selektierbar sind.
    Ein cStatus-Objekt hat keine Information darüber, wie viele Zeilen das OSD darstellen kann, und welche Items momentan sichtbar sind.
    cStatus::MsgOsdCurrentItem() wird mit dem Text des selektierten Items aufgerufen. Hier fehlt eigentlich der Index. Genau genommen könnte man sich hier den Text sparen, weil ja zuvor schon alle Texte mitgeteilt wurden, aber dann müsste ein cStatus, das nur an dem aktuell selektierten Text interessiert ist, alle Texte speichern, was unnötiger Aufwand wäre.

    Wenn sich Text auf einem OSD, das gerade gebaut wird, aber noch nicht angezeigt wird, ändert, dann wird keine Methode aufgerufen. Also im oben genannten Fall 2b.

    cStatus hat kein Konzept von "noch nicht angezeigt". Wie oben geschildert bekommt es die Info über alle Items, und welches selektiert ist. Mehr nicht. Eine neue Funktion cStatus::OsdCurrentItem2(const char *Text, int Index) wäre also akzeptabel, alles weitere übersteigt eigentlich das Konzept von cStatus.

  • cStatus::MsgOsdCurrentItem wird nicht nur in Display() gerufen, sondern auch in menuitems.c void cMenuEditItem::SetValue(const char *Value) .

    Ein Beispiel für die Abfolge dieser Aufrufe:

    Code
    cStatus::MsgOsdCurrentItem("Beispiel Attibut\t 5");
         (hier stellt das vom Plugin implementierte Display den Text "Beispiel Attibut\t 5" schon mal dar)
    cStatus::MsgOsdItem("Attibute", 0, true);
         (hier wird "Beispiel Attibut\t 5" zu "Attibute" geändert. Nicht soo schlimm, aber irgendwie unschön)
    cStatus::MsgOsdItem("Beispiel Attibut\t 5", 1, true);
    ... (User selectiert Zeile mit Index 1)
    cStatus::MsgOsdCurrentItem("Beispiel Attibut\t 5");
    ... (User ändert das Attribut zu 7)
    cStatus::MsgOsdCurrentItem("Beispiel Attibut\t 7");

    Der erste Aufruf ist unschön, weil er erfolgt, bevor cStatus::MsgOsdItem(..) gerufen wurde.

    Mit dem Patch OsdItemSelected_2.txt bekommen wir im gleichen Beispiel:

    Code
    cStatus::MsgOsdItem("Attibute", 0, true)
    cStatus::MsgOsdItem("Beispiel Attibut\t 5", 1, true);
    ... (User selectiert Zeile mit Index 1)
    cStatus::MsgOsdItemSelected(1);
    ... (User ändert das Attribut zu 7)
    cStatus::MsgOsdItemChanged("Beispiel Attibut\t 7");

    Trotzdem kann ich verstehen, wenn Dir OsdItemSelected_2.txt zu weit geht.

    Aber cStatus::OsdCurrentItem2(const char *Text, int Index) zu implementieren ist auch nicht ganz einfach, da der Index nicht überall verfügbar ist, wo VDR diese Methode aufruft. Wenn das zu ungenau beschrieben ist: Versuche doch einfach mal selbst, cStatus::OsdCurrentItem2(const char *Text, int Index) zu implementieren.

    Ev. habe ich aber etwas übersehen, und cStatus::OsdCurrentItem2(const char *Text, int Index) ist doch ganz einfach machbar. Wäre für mich auch O.K.

    Ansonsten können wir ja auf https://www.vdr-portal.de/attachment/503…selected-1-txt/ zurückgreifen.

    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Ich habe den Patch vdr-2.7.3-status-osditem_3.diff.txt angewendet und das Beispielplugin "status" so geändert:

    Wenn ich damit die Menü-Taste drücke erscheint im Log:

    Mal abgesehen davon, dass OsdHelpKeys zweimal kommt (dem werde ich nachgehen), kommt OsdCurrentItem erst nach allen OsdItem2.
    Drücke ich jetzt '7' kommt

    was etwas verwundert, da erst das Hauptmenu nochmal kommt (dem werde ich auch nachgehen), aber danach kommen auch wieder alle OsdItem2 vor dem OsdCurrentItem.

    Wähle ich dann '1' sehe ich

    Auch hier wird das Menü zweimal gelistet (wie oben), und ich denke mal, es sind die Zeilen

    Code
    OsdCurrentItem Language:#0110 
    OsdCurrentItem Language:#011English 
    ...

    am Anfang, die die Probleme machen, oder?

  • Hi Klaus,

    vielen Dank für die detaillierte Analyse. Probleme macht, dass

    Code
    OsdCurrentItem Language:#011English 

    vor

    Code
    OsdItem2  Language:#011English 0 1 

    aufgerufen wird.

    Für mich definieren die OsdItem2 Aufrufe das Menü.

    Die OsdCurrentItem geben Informationen über Veränderungen im aktuellen Menü (selektierte Zeile / anderer Text).

    Daher ist für mich die Reihenfolge wichtig:

    1. Das Menü wird definiert (OsdItem2)
    2. Ich erhalte Informationen über Änderungen im vorher definierten Menü (OsdCurrentItem).

    Klar, wenn OsdCurrentItem die Zeileninformation enthalten würde, könnte ich auch OsdCurrentItem zum Aufbau des Menüs verwenden. Und dann kommt OsdClear, und dann kommt nochmal das Menü mit OsdItem2. Macht irgendwie keinen Sinn.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • So wie's aussieht könnte das hier die Lösung für das Problem mit den zu frühen OsdCurrentItem()-Aufrufen sein:

    Diff
    --- menuitems.c 2024/07/13 09:12:18     5.2 
    +++ menuitems.c 2025/01/28 11:58:07 
    @@ -38,7 +38,6 @@ 
    { 
      cString buffer = cString::sprintf("%s:\t%s", name, Value); 
      SetText(buffer); 
    -  cStatus::MsgOsdCurrentItem(buffer); 
    } 
    
    void cMenuEditItem::SetHelp(const char *Red, const char *Green, const char *Yellow, const char *Blue)

    MarkusE Magst du das bitte mal testen?
    An den anderen Punkten bin ich noch dran.

  • Der Fehler, dass beim Drücken eines Hotkeys (0-9) das aktuelle Menü nochmal dargestellt wird, dürfte hiermit behoben sein:

    Diff
    --- osdbase.c   2025/01/16 09:42:11     5.2 
    +++ osdbase.c   2025/01/28 12:55:08 
    @@ -501,7 +501,6 @@ 
             if (*s == Key - k1 + '1') { 
                current = item->Index(); 
                RefreshCurrent(); 
    -            Display(); 
                cRemote::Put(kOk, true); 
                break; 
                }
  • So wie's aussieht könnte das hier die Lösung für das Problem mit den zu frühen OsdCurrentItem()-Aufrufen sein:

    Diff
    --- menuitems.c 2024/07/13 09:12:18     5.2 
    +++ menuitems.c 2025/01/28 11:58:07 
    @@ -38,7 +38,6 @@ 
    { 
      cString buffer = cString::sprintf("%s:\t%s", name, Value); 
      SetText(buffer); 
    -  cStatus::MsgOsdCurrentItem(buffer); 
    } 
    
    void cMenuEditItem::SetHelp(const char *Red, const char *Green, const char *Yellow, const char *Blue)

    MarkusE Magst du das bitte mal testen?
    An den anderen Punkten bin ich noch dran.

    Na ja, das löst ein Problem (zu frühe OsdCurrentItem()-Aufrufe). Aber: Wenn ein Anwender dann einen Wert im Setup ändert, bekomme ich es nicht mehr mit :( .

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Wie bisher auch, über OsdCurrentItem():

  • Code
    cStatusTest::OsdCurrentItem Multi speed mode:#011yes

    Aber das kommt doch nicht mehr, wenn Du

    Code
    cStatus::MsgOsdCurrentItem(buffer); 

    aus menuitems.c (Methode void cMenuEditItem::SetValue(const char *Value) ) herausnimmst (?). Also, wenn Du es da herausnimmst, wo wird dann Status::MsgOsdCurrentItem(buffer); beim Ändern des Attributes gerufen? Von void cOsdMenu::DisplayCurrent(bool Current) oder von void cOsdMenu::DisplayItem(cOsdItem *Item)?


    Warum hast Du "damals" den Aufruf von cStatusTest::OsdCurrentItem in menuitems.c (Methode void cMenuEditItem::SetValue(const char *Value) ) eingebaut?

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • wo wird dann Status::MsgOsdCurrentItem(buffer); beim Ändern des Attributes gerufen?

    Aus cOsdMenu::DisplayCurrent().

    Warum hast Du "damals" den Aufruf von cStatusTest::OsdCurrentItem in menuitems.c (Methode void cMenuEditItem::SetValue(const char *Value) ) eingebaut?

    Das weiß ich nicht (mehr) ;-).

    Magst du es bitte mal in deiner konkreten Umgebung ausprobieren?

  • OK, Ich werde testen.

    1. Beobachtung: DisplayCurrent(true); wird sehr oft gerufen.

    Vorschlag für eOSState cOsdMenu::ProcessKey(eKeys Key):

    Code
    if (marked < 0 && item) {
      eOSState state = item->ProcessKey(Key);
      if (state != osUnknown) {
    -   DisplayCurrent(true);                                                                                                                 
    +   if (Key != kNone) DisplayCurrent(true);

    Ev. könnte man Key != kNone auch schon früher prüfen. Wofür wird das benötigt?

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!