Posts by kls

    Ich habe den Patch mit folgenden Änderungen übernommen:
    1.) In den Interfaces erst Type, dann Message (passt besser zu entsprechenden anderen Stellen).
    2.) Kein Defaultwert für Type in MsgOsdStatusMessage() (wegen 1.), daher eine zusätzliche Funktion und die bisherige "deprecated".

    MarkusE Passt das so für dich?

    Bei den Untersuchungen zum Thema cStatus ist mir noch aufgefallen, dass beim Scrollen jedes Mal für alle Items OsdItem2() aufgerufen wird, was an dieser Stelle völlig unnötig ist. Beiliegender Patch (nach vdr-2.7.3-status-01.diff.txt anzuwenden) behebt das.
    MarkusE Magst du dir das bitte auch anschauen? Ich versuche jetzt noch herauszubekommen, warum das Menü bei ersten Mal manchmal zweimal aufgebaut wird (habe ich erst durch die doppelten Aufrufe von OsdItem2() gesehen). Das ist auch unnötig und vermutlich auch ohne Verwendung von cStatus schlecht für die Performance.

    Danke, das wäre auch mein nächster Schritt gewesen ;-).

    Anbei zum Abgleich der komplette Stand der Änderungen bzgl. Statusmeldungen.
    Bei den Aufrufen von MsgOsdCurrentItem() habe ich anstatt Item->Index() den jeweils an dieser Stelle bereits vorhandenen Wert genommen, da Index() die Liste durchläuft und "zählt", was hier aber unnötig ist, da der Wert bereits bekannt ist.

    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?

    Wie bisher auch, über OsdCurrentItem():

    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.

    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?

    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.