Kodi Community Forum

I have a bunch of radio button toggles that i want to be enabled when the skin is installed, how do i achieve this?

The usual trick is inverting them so that the default setting of "false" actually means "true".

Hi @jmarshall,
I can see this is a REALLY old post... but still ran into this now and can't find a better thread that discusses this.

I want to achieve something similar, and don't think a true/false trick will do here.
I'm using a string setting, not boolean. So I define all kinds of checks for this string using StringCompare(Skin.String(nameOfString),CompareString).

Trying your described trick, means I have to create a "default" first condition that looks something like this:

This gets really cumbersome with multiple possibilities for this setting.
So is there a better way to explicitly set this string to default value? Maybe using the Startup.xml with the <onload> tag?

Any help will be appreciated!

Could you not use <condition=IsEmpty(Skin.String(nameofString)>Option1</condition>?

(2014-04-13, 19:55)Sranshaft Wrote: [ -> ]Could you not use <condition=IsEmpty(Skin.String(nameofString)>Option1</condition>?

That wouldn't work once the option has been chosen.
Meaning - if the user cycles through all options back to option1, this condition will fail.
Of course, I can do:

...but I'm just really hard on myself when it comes to simple, efficient & readable code

Just reset the string upon selecting the last option.

(2014-04-14, 00:55)Hitcher Wrote: [ -> ]Just reset the string upon selecting the last option.

I didn't know I can use Skin.Reset(nameOfString) on string values... is that possible?
And, if I'm following you - for the "option1" condition I would use IsEmpty(Skin.String(nameOfString)) only?

Yes.

Thanks, tried this and it works perfectly!

Hi @Hitcher, sorry to bring this up again... but I think I've stumbled upon a bug here, maybe you can assist?
I've used this and it was working fine - until I tested on Frodo...

Here's my code, from skin settings:

Here's the variable:

When on Gotham, works perfectly as I said before - the correct <onclick> is chosen when you press the button, the the string is either set to "aired" or reset. The variable changes accordingly, and most importantly - the actual items in the corresponding list change from recently added to recently aired. Oh joy

On Frodo... nothing happens. The label does not change, neither do the items that check for this value (the list still displays recently added items).
Here's a link to a pastebin when debugging both Frodo and then Gotham: http://xbmclogs.com/show.php?id=175134
(zoom in to the area where there's a bunch of "Select" presses)
I can see two things here:

1. Frodo tries to translate the strings, Gotham is not. (maybe both are doing it, but only Frodo is logging it?)
   
2. It seems that in Frodo, when pressing Select, XBMC is trying to parse BOTH <onclick> definitions??
   

This makes me think that for some reason, Frodo goes through all <onclick>s in the button, which makes a loop on itself and causes nothing to happen: the first <onclick> condition is true, so the string is set to "aired". Then, the second <onclick> is checked - and now it's true... so the string is reset. Result - nothing happened.
I tried to test this theory by switching the order of the <onclick>s:
...and it works (kinda) - the label changed to "recently aired", and then it was stuck like that... so the loop started happening again, just from a different starting point...? And - the list of items did not update, it just became blank. Very weird

Is there a limitation regarding Skin Strings and condition="..." in Frodo?
I'm asking because in another place where I use Skin Strings for default settings, I do it differently: instead of having multiple <onclick>s, I have multiple buttons - one for each condition, and just use <visible> to display/hide them.

Again - this only happens in Frodo.

p.s. I think this limitation also applies to <include condition="..."> tags.

@EtgarDizz - On Frodo you used to have to include the first condition at the end again for onclick commands - this may have been fixed for Gotham. I'm not sure if this is the issue here and I have no idea why it does it but 99% of the time I find it ends up being this.

example

Also note how the conditions change upwards rather than downwards.

Try changing yours to the following, it seems bizarre but I wouldn't be at all surprised if it works.

@jurialmunkey,

Thanks for the insight, I didn't know about this bug, and it certainly explains this behaviour.
I tried your suggestion and it solved the control's <onclick> problem. However, it did not solve the <include> problem I mentioned at the end of my previous post.

I have 3 places that address this skin setting:

After I added your suggestion, the settings button worked, and the label on it was also functioning properly.
However, when going to the gui, the user-display was showing nothing. Apparently, no <include> was triggered.
Moreover - when I clicked again (supposedly resetting the string), still no items were showed!

Some theories...

1. Can't use condition="StringCompare(Skin.String(...)))" in an <include> tag
   
2. Even when resetting, it's not really reset, but changed to "" (empty string), which doesn't trigger the IsEmpty() condition
   

Any of this make sense??

Try removing one of the onclick reset conditions (no need for 2) and also try using -

andfor the includes.

Are the includes loaded on another window to the setting button?

(2014-04-16, 19:06)Hitcher Wrote: [ -> ]

Code:

IsEmpty(Skin.String(TVType))

and

Code:

!IsEmpty(Skin.String(TVType))

for the includes.

How does this address the fact that even after resetting the string, the IsEmpty() condition doesn't fire?

(2014-04-16, 19:06)Hitcher Wrote: [ -> ]Are the includes loaded on another window to the setting button?

Yes. The includes are loaded when the items are supposed to be displayed to the user, ie in a different window outside the skin settings window.

Why not use a toggle button if there's only two values?