Hi Asad,

I do not understand your question or what you mean by "use of it dynamically".

Module Settings is just a convenient built in system you can use to persist content feature instance settings as well as feature defaults for those settings. It provides a user interface ModuleSettings.aspx and a way to have localized labels for your settings. That is all it does and that is all it was meant to do. If you find it useful use it, if not you can implement your own way to manage settings. This is a built in convenience so we don't have to implement a way to store feature instance settings over and over in each feature. Typically in existing features we populate some local variables based on the module settings in a LoadSettings method. Module settings for a given module are actually retrieved all at once (by moduleid) into a hashtable, then you are accessing them one by one to read them from the hashtable. This is what makes it flexible we can have as many settings as we need.

Hope it helps,

Joe

The default settings are stored in the feature definition file so the setup system can install the defaults into a new database upon installation. The defaults get copied into the mp_ModuleDefinitionSettings table during setup. When a new instance of a feature is created on a page the instance will have the default values for all settings which go into mp_ModuleSettings but these can be modified to configure the instance. So these settings are useful when you have settings for features that you want users to be able to configure differently for each instance of your feature. If you don't find it useful then you are free to implement your own way doing things and don't have to use module settings. I find it very useful for many features because its already built and I don't have to implement setting storage over and over every time I make a new feature. If that seems useful to you then you can use it for storing settings for your own custom features too.

Hope it helps,

Joe