release: Config file module
BlitzMax Forums/BlitzMax Programming/release: Config file module
| ||
| Here is a pretty feature-rich module to deal with config/ini files. It allows you to read from, write to, modify and deal with key/value paired ini files. If you have the need to work with these types of files, you would seriously benefit from this module! You can download it here: http://code.google.com/p/jmd-blitzmax-modules/downloads/list Here is a simple example of some of the features: config.ini: ;this is a comment app_width=640 app_height = 480 ;this is also a comment! title= example.bmx:
uperStrict
Import jmd.cfg
'Create a new instance and read in the file
Global cfg:TConfig=CreateConfig("config.ini")
ConfigRead(cfg) 'note, could have used autoRead parameter in the CreateConfig() function above
'Set up defaults, and load them in!
Local defaults:TMap = CreateMap()
defaults.insert("app_width","1024")
defaults.insert("app_height","768")
defaults.insert("title","Example TConfig usage")
defaults.insert("name","John Doe") 'this key/value pair was purposely left out of config.ini to show that the default works
ConfigSetDefaults(cfg,defaults)
'Get the information!
Print "Application Width: " + ConfigGetString(cfg,"app_width")
Print "Application Height: " + ConfigGetString(cfg,"app_height")
Print "Title: " + ConfigGetString(cfg,"title")
Print "Name: " + ConfigGetString(cfg,"name")
'Now lets make some changes!
ConfigUpdate(cfg,"name","Jane Doe",False) 'Since it doesn't exist, and the autoCreate parameter is false, nothing will happen!
'Notice that it doesn't work this time
Print "Name: " + ConfigGetString(cfg,"name")
ConfigUpdate(cfg,"name","Jane Doe",True) 'Now the autoCreate parameter is true! Note that this change won't permanently be saved to the file unless we call the ConfigWrite() function
'But now it does thanks to the autoCreate parameter being true!
Print "Name: " + ConfigGetString(cfg,"name")
'Now, lets try to get the value for a key that doesn't exist!
Print "Random number: " + ConfigGetString(cfg,"random")
'Lets add it!
ConfigAdd(cfg,"random",String(Rnd(1,10)))
Print "Random number: " + ConfigGetString(cfg,"random")
'Check to see if certain key/value pairs exist
If ConfigContains(cfg,"name")
Print "name key found!"
Else
Print "name key NOT found!"
EndIf
If ConfigContains(cfg,"address")
Print "address key found!"
Else
Print "address key NOT found!"
EndIf
'Uncomment below, and the changes will be saved to the file!
'ConfigWrite(cfg)
|
| ||
| does it support sections? e.g. fullscreen = true [Options] showdebug = false etc etc.. |
| ||
| No, not currently, but it isn't a bad idea |
| ||
| Not to steal your thunder :P but I believe Muttley has produced an ini file reader before. I personally use Brucey's xml module and store my stuff in xml files. They are more expressive than ini files. |
| ||
| No harm in having lots of choice though :-) I have 2 xml parsing modules... choice is good ! |
| ||
| Yeah, I knew there was already a couple of ini file readers around, but I wanted to build one to work exactly how I wanted it to, plus have an in-depth knowledge of how it works under the hood. |
| ||
| @Leon Drake: My INI File Handler module (check the muttmods link in my sig) supports sections. As Brucey says though, the more choices the better. :) |
| ||
| cool. i will say using xml to store config stuff is great, but i do like the ease of using INI files for users who may need to make a change to options without having to load the app, as its easier on the eyes to find what you need to modify |
| ||
| Oh, and there's a config file thingy with wxMax which can be configured to use an ini file format or the Registry (on Windows) - if you like that kind of thing :-) |
| ||
Leon, xml was designed to be easy for humans to read!<settings xres="1024" yres="768" fullscreen="0" depth="32" updatespeed="30"/> |
| ||
| @czar, yea i know.. but meant y'know for stupid people. |
| ||
| They're also massive and wasteful. Then there's the problem that XML requires rather specific formatting needs (much like JSON). Which is a big no-no for anything that is to be used for regular old mortals. ini files may feel too simple, but they work and there is very little chance of someone messing those up. |
| ||
| Indeed, and you can stipulate your own specific formatting. Not for data protection, but merely for convenience. |
| ||
| They're also massive and wasteful. Then there's the problem that XML requires rather specific formatting needs (much like JSON). Which is a big no-no for anything that is to be used for regular old mortals. ini files may feel too simple, but they work and there is very little chance of someone messing those up. Well, in all fairness, XML solved one of the many problems of the IT industry: How to add more complexity to otherwise trivial tasks so that we all stay in business... |
| ||
| Massive and wasteful???? 4kb file instead of 3.5kb?? Oh no! |
| ||
| > Massive and wasteful???? 4kb file instead of 3.5kb?? Oh no! On the small end it may not look bad (to be fair most ini files don't get that large), XML bloat really adds up when using it for transferring data back and forth from a database table. To me, XML was a solution looking for a problem. I agree with Winni too. |
   |