Probably there is not, but you can use the Clamp function to limit the value. For example if you're using a !SetVariable bang to set the entered value to a variable (Command1=[!SetVariable MyVariable "$UserInput$"]), you can limit this value as it follows: Command1=[!SetVariable MyVariable "(Clamp($UserInput$,0,10))"] (obviously you have to edit the limits of the above Clamp function to whatever you do need).

The difference between defining them in the [Rainmeter] section of the skin .ini file, and defining them in the [ConfigName] section in Rainmter.ini is that if it is in Rainmeter.ini, then it is based on the config name, and if you have more than one skin variant that shares that config name, they automatically all get the group attribute. If you define it in the skin .ini, then only that variant will be a member of the group. Having said that though, you also need to consider if you have multiple Layouts that contain your skins, as if you want this attribute to be available in any Layout, you would need to add it to the [ConfigName] option in each, where doing it in the skin .ini makes it specific to the skin / variant and nothing else would ever need to be done.

If you are going to be sharing your skins, and want this Group functionality to be a part of things for users who get your skins, I'd be tempted to put the Group option in the skin .ini file, as you have little or no control over how people manage their Layouts.

So which way you go is up to you, depending on how you intend to use the Group functionality.

i put it in the skins as a group because it will be widely shared and that way it does the job well. It also looks like a more familiar option to me. Firstly i wanted to cut short writing all the skin names in every refresh function. It would also be bringing a headache if one would change a skin's name etc.
Thanks for the thorough explanation of that!

Becaue #RootConfig# is a unique name, using Group=#RootConfig# will add the current skin to a group of skins with the name of the Root Skin Folder where the skin is located.

This has several benefits, the main one being able to control every skin in your suite of skins specifically when you need to refresh all of them, but do not want to refresh every skin an end user has loaded, the way !RefreshApp would do.

Also, if the end user wants to change the Root Skin folder name, all of the skins will still be associated with that "new skin folder name" group.