Organini - simple module for INI files

[Petr Schreiber]

Hi,

we all know the classic INI module in ThinBASIC. It follows patterns from other languages, and is quite straightforward:


Uses "Ini"

' -- Declare new variable
$myFile = APP_SourcePath + "settings2.ini"

INI_SetKey($myFile, "Screen", "Width", 1920)
INI_SetKey($myFile, "Screen", "Height", 1080)
INI_SetKey($myFile, "Screen", "Depth", 32)

INI_SetKey($myFile, "User", "Name", "Petr")
INI_SetKey($myFile, "User", "Password", "1234")

' -- Display the data
Long xRes = INI_GetKey($myFile, "Screen", "Width", "")
Long yRes = INI_GetKey($myFile, "Screen", "Height", "")

MsgBox 0, xRes + "x" + yRes


Code looks okay, but writing it makes you break your fingers - repeating the functions, then specifying file for each call, then explicit reading...

What about having settings done more naturally? I tried to reinvent the syntax approach and came up with the concept of "Organini" module (from Organic INI). The code then looks like this:


Uses "Organini"

' -- Hook it to any file you need
Dim config As Organini
config = New Organini(APP_SourcePath + "settings.ini")

' -- Write data this way - first is section, then key
config.Screen.Width = 1920
config.Screen.Height = 1080
config.Screen.Depth = 32

config.User.Name = "Petr"
config.User.Password = "1234"

' -- Read the data back easily - this reads always up to date data from file!
MsgBox 0, config.Screen.Width + "x" + config.Screen.Height


What do you think about it ;)? It has its issues - like upper casing the sections and keys in file, but otherwise it is one of the many magical things current ThinBASIC SDK allows module authors to do.


Petr

[ErosOlmi]

Petr's magic as usual.
Very clever, very nice.

[ErosOlmi]

Petr,

maybe the optional default value is missing in "reading" an INI value.
Something like:


config.Screen.Width(1920)

where "(1920)" is the default value in case "Screen.Width" section/parameter is not found in INI file

But its usage/presence should be optionally parsed and not mandatory.

I think after that I could add as standard module if you like.
Only doubt is ... name of the module :onthequiet:always remind me "orgasmic ini" but maybe it is my current attitude :D

Ciao
Eros

[ReneMiner]

i don't get it: how does it know ".Screen.Width" has to be some function that extends a config-udt-variable (is it one at all?) and how does it accept "= assignsomething".

Not possible in plain basic- right?

Else i would be very nosy how i can have dynamic function-names & udt-subelements being accepted by the "varname.[noMatterWhatfollowsHere]"

...
And, for the UCase-thing:
Why not simply:


Dim myIni As t_someInifile

myIni.Init(sFilename)
Printl myIni.GetKey(sSection,sKeyname, sDefaultvalue)
myIni.SetKey(sSection, sKeyname, sKeyvalue)

[Petr Schreiber]

...yeah, and why not rename module for assembly language OrgASM, right? :p

Eros, if you can/want, add this class to INI file module in default ThinBASIC installation - I attached full source code in the first post of this thread :). It supports default values now too, thanks for the suggestion!:


Uses "Organini"

' -- Hook it to any file you need
Dim config As Organini
config = New Organini(APP_SourcePath + "settings.ini")

' -- Write data this way - first is section, then key
config.Screen.Width = 1920
config.Screen.Height = 1080

' -- Read the data back easily - this reads always up to date data from file!
' -- Default value can be specified in brackets
MsgBox 0, config.Screen.Width + "x" + config.Screen.Height + "@" + config.Screen.BitDepth(32)


Also - one more wish. Do you think, you could add my StringBuilder to default installation too? It can be downloaded here:
https://github.com/petrSchreiber/thinBasic_StringBuilder

...and it is also documented there (https://github.com/petrSchreiber/thinBasic_StringBuilder/wiki). I think you can just put link to the GitHub to help file.


Petr

[Petr Schreiber]

...maybe world really isn't prepared for OrganINI :p

I attach here more conventional approach as Rene suggested. Maybe both can coexist inside Ini module.



Uses "IniFile"

' -- Hook it to any file you need
Dim config As IniFile
config = New IniFile(APP_SourcePath + "settings.ini")

' -- Write data this way - first is section, then key
config.SetKey("Screen", "Width", "1920")
config.SetKey("Screen", "Height", "1080")

' -- Read the data back
MsgBox 0, config.GetKey("Screen", "Width") + "x" + config.GetKey("Screen", "Height") + "@" + config.GetKey("Screen", "BitDepth", "32")



Petr

[ReneMiner]

...maybe world really isn't prepared for OrganINI :p
...
Indeed i like better if modules-syntax is closer to thinBasic-script-syntax. ;)

Still nosy about the first approach- is there some way to add arbitrary subelements to a variable without having to Type them?

Is it done by thinBasic_AddUDT-function? Is it an udt at all?
How is it dynamic so one still can add additionally subelements after accessing it once?

Is it some sort of parsing the code? How can i allow the user to append and instantly pass something like ".Screen.Width" and how does it know what to do with it? Is that possible in thinBasic at all?

& not to critizise but "IniFile" is misleading module-name since not combination of Ini & File-modules,

but perhaps it's a "cIni" similar as "cTimer" - class ?

every app should have an .ini in these days...

What about Ini_GetSectionsList & Ini_GetSectionKeyList ?
Would that be possible = complete overhaul of classic ini-module... - who uses this doesn't need for two functions also have to use classic ini.

your example above, assume Uses "Console" ...


PrintL config.SetKey("Screen", "Width", "1920")
PrintL config.SetKey("Screen", "Height", "1080")

could print out/return the keyvalues here to enable instant assignement if needed when creating default-ini-data for something.

[Petr Schreiber]

Hi Rene,

answers to your questions regarding "how it works" are available when you download the source code of the module from the first post of this thread. No UDT is built, but I take advantage of information ThinBASIC gives me about token parsing.

I am not big fan of c prefix, and Ini could be shortcut for ... Inter-Network Interface for example, so that is why I decided to add the "File" to it, to identify it further :)

I implemented your requests, please see in dedicated thread for IniFile module:
http://www.thinbasic.com/community/showthread.php?12563-IniFile-module-for-INI-file-handling&p=91998#post91998


Petr

[ReneMiner]

Very nice. Complete modern-times replacement for classic Ini-module.

(this the answer to the other thread - but i did not want to get to far off topic there since it's still clean from topic-foreign-discussions)

Something like that i'd wish too for TBass-module, channel-section

( + for color-types, fonts, UI-controls + windows, textures, entities, sprites, strings [,heap-memory],...
so basically anything where objects are represented by a handle, Ptr or ID currently) :D

attached a testing-sample, a raw sketch what i imagine for an overhauled TBass-module, but written in thinBasic, have an eye on tSound-Unit mostly.
I should have better named it tSoundChannel probably...
(testPerc.tBasic is to test the unit, it random plays 1 out of 3 percussion-sounds)

It's just making the channel-dword functional here, so instead of TBass_ChannelPlay(mychannel, %TBass_True) its just mychannel.Play() etc.
I'm not sure if module-classes are able to have static members as thinBasic-types can have, but imo static members are good place for class-specific common values, settings, flags etc.

[ReneMiner]

Now you can probably see the reason why i would like to be able to Extends <standard_numerical_types>,
for more see this post:
http://www.thinbasic.com/community/showthread.php?12554-Type-As

[Petr Schreiber]

Hi Rene,

I agree it would be generally good design move to treat UDT and standard types equally. It would be also good for cases like fast declare:


Long myNumber ' -- Possible now

MyCustomType variable ' -- Not possible now, because UDTs are considered something special



Petr

[ReneMiner]

yes, there is some difference i also recognized when Type_Exists("Byte") did return False in the beginning.
But if udt or primitive type: both are variable-types and should be useable the same way basically.