As the subject says. ST:TNG is the only skin where this happens, since it shares the same line for both things. And you can see the "remains" of the message in the space between each button. Maybe I'm wrong, but I shouldn't be forced to stop calling SetButtons if there's a message active (at least if I repeatedly[*] call SetButtons after calling SetMessage it works fine with every other skin).
[*] I change the help at each screen refresh based on the menu selection, while I only need to show a message from time to time.
Bye
Luca Olivetti wrote:
As the subject says. ST:TNG is the only skin where this happens, since it shares the same line for both things. And you can see the "remains" of the message in the space between each button. Maybe I'm wrong, but I shouldn't be forced to stop calling SetButtons if there's a message active (at least if I repeatedly[*] call SetButtons after calling SetMessage it works fine with every other skin).
[*] I change the help at each screen refresh based on the menu selection, while I only need to show a message from time to time.
Well, I can check 'message' in cSkinSTTNGDisplayMenu::SetButtons(), and not set the buttons if it is true, but that will result in the buttons having their _old_ values after the message disappears.
Generally the buttons are not supposed to be changed while a message is being displayed. Ok, I haven't written that anywhere explicitly, but that's how it's meant, so I can add that remark if you like.
Klaus
Klaus Schmidinger wrote:
Luca Olivetti wrote:
As the subject says. ST:TNG is the only skin where this happens, since it shares the same line for both things. And you can see the "remains" of the message in the space between each button. Maybe I'm wrong, but I shouldn't be forced to stop calling SetButtons if there's a message active (at least if I repeatedly[*] call SetButtons after calling SetMessage it works fine with every other skin).
[*] I change the help at each screen refresh based on the menu selection, while I only need to show a message from time to time.
Well, I can check 'message' in cSkinSTTNGDisplayMenu::SetButtons(), and not set the buttons if it is true, but that will result in the buttons having their _old_ values after the message disappears.
And restoring the buttons in SetMessage would completely solve the problem, thanks ;-)
Generally the buttons are not supposed to be changed while a message is being displayed. Ok, I haven't written that anywhere explicitly, but that's how it's meant, so I can add that remark if you like.
Well, of 7 skins I tried (5 of them text2skin), the only one that didn't work was ST:TNG, so I suppose that's the one that is not working according to the specs.
Bye
Luca Olivetti wrote:
Klaus Schmidinger wrote:
Luca Olivetti wrote:
As the subject says. ST:TNG is the only skin where this happens, since it shares the same line for both things. And you can see the "remains" of the message in the space between each button. Maybe I'm wrong, but I shouldn't be forced to stop calling SetButtons if there's a message active (at least if I repeatedly[*] call SetButtons after calling SetMessage it works fine with every other skin).
[*] I change the help at each screen refresh based on the menu selection, while I only need to show a message from time to time.
Well, I can check 'message' in cSkinSTTNGDisplayMenu::SetButtons(), and not set the buttons if it is true, but that will result in the buttons having their _old_ values after the message disappears.
And restoring the buttons in SetMessage would completely solve the problem, thanks ;-)
Generally the buttons are not supposed to be changed while a message is being displayed. Ok, I haven't written that anywhere explicitly, but that's how it's meant, so I can add that remark if you like.
Well, of 7 skins I tried (5 of them text2skin), the only one that didn't work was ST:TNG, so I suppose that's the one that is not working according to the specs.
Well, since it's me who writes the specs <g> I'll specify it so that "a skin shall not call SetButtons() while a message is being displayed". That's because while there is a message on the screen, the user shall not be distracted by anything else wobbling around on the screen.
Klaus
Klaus Schmidinger wrote:
Well, since it's me who writes the specs <g> I'll specify it so that "a skin shall not call SetButtons() while a message is being displayed". That's because while there is a message on the screen, the user shall not be distracted by anything else wobbling around on the screen.
So this will "fix" st:tng and break every other skin :-( (since In every other skin the message area and the buttons area are separate and independent).
Bye
Luca Olivetti wrote:
Klaus Schmidinger wrote:
Well, since it's me who writes the specs <g> I'll specify it so that "a skin shall not call SetButtons() while a message is being displayed". That's because while there is a message on the screen, the user shall not be distracted by anything else wobbling around on the screen.
So this will "fix" st:tng and break every other skin :-( (since In every other skin the message area and the buttons area are separate and independent).
This won't "break" anything! All skins will work just as they did before. It may only "break" some plugins that use a cSkinDisplayMenu and call SetButtons() while a message is displayed.
Besides, it says in skins.h:
virtual void SetMessage(eMessageType Type, const char *Text) = 0; ///< Sets a one line message Text, with the given Type. Type can be used ///< to determine, e.g., the colors for displaying the Text. ///< If Text is NULL, any previously displayed message must be removed, and ///< any previous contents overwritten by the message must be restored.
The last sentence should have indicated that the skin is free to display the message wherever it wants, maybe even within a framed box in the middle of the screen. Maybe I should have added (and I guess I actually will) that while a message is being displayed, no other changes to the menu should be made.
Klaus
Klaus Schmidinger wrote:
This won't "break" anything! All skins will work just as they did before. It may only "break" some plugins that use a cSkinDisplayMenu and call SetButtons() while a message is displayed.
well, it happens I have a real need for that, and I found it extremely useful that it worked and I could change both the message and the buttons at will. In fact it doesn't work just on one skin out of 7, but now that I know you aren't going to fix it I'll try a way to workaround it so that the plugin works even with st:tng (or maybe not, my day too is limited to 24hours, and I don't use st:tng anyway ;-)
Bye
Klaus Schmidinger wrote:
Well, since it's me who writes the specs <g> I'll specify it so that "a skin shall not call SetButtons() while a message is being displayed". That's because while there is a message on the screen, the user shall not be distracted by anything else wobbling around on the screen.
Well, I worked around it in my plugin. Please don't change anything to enforce this rule since it's working fine here without it. BTW, the fix is a trivial one if done in cOsdMenu (I did it in my class replacing it). Bye
-
Klaus Schmidinger -
Luca Olivetti