Looking for a tutorial for ini Files and AutoIT, really lost here

[JayHawkfl]

I'm not asking anyone to explain how to make it work, if you can thats great but I am 3/4 of a program in to learning AutoIT and have 0 experience with ini files but I need to make this work. Where can I go to learn? I haven't found anything that has the code AND the ini file, I need examples of AutoIT and .ini working in harmony. Something to point be in the right direction.

Just to drive this point home. When you punch in "iniread(" you get the sticky note that says "filename, section, key, default" I know what a file name is and I have the correct file path but I don't know what the other three things are refrenceing or if they are refrenceing something in AutoIT or in the ini file.

[MrMitchell]

Check the Help File for what everything means. The INI goes like this...

[section]

Key=Value

Key2=Value2

...

Default is what will be returned if the key can't be found.

You can find INI files everywhere on your PC, check C:windows, for example.

If you have the full installation of AutoIt, while your cursor is on INIRead() function press F1 and the Help File should open up to that function.

Edited September 20, 2012 by MrMitchell

[BrewManNH]

[Test1]
1=1
2=2
3=3
4=4
[Test2]
1=1
2=2
3=3
[Test3]
1=1
2=2
3=3

This is an example of a typical INI file. Section refers to any text between square brackets ("[ ]"), in this example Test1, Test2 and Test3 are section names. Key refers to anything that is to the left of the first equals sign ("=") in each line after the Section name, the Value is what is to the right of the equals sign and is what is read when doing an IniRead. Default is what the function is to return if there is nothing that matches the section name, or the key name in the file.

[DicatoroftheUSA]

As a side note, you may want to focus your efforts on XML, unless you want to mess with existing .ini's. It seems that is what modern programs are using where they used to use ini files.

Plus the included functions do not have an options to comment INI's, but course you can roll your own.

Edited September 20, 2012 by DicatoroftheUSA

[GordonFreeman]

#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
#Region ### START Koda GUI section ### Form=
$Form1 = GUICreate("IniRead", 209, 46, 192, 124)
$Label1 = GUICtrlCreateLabel("Label1", 16, 8, 180, 28)
GUICtrlSetFont(-1, 14, 400, 0, "MS Sans Serif")
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###

;CODE

GUICtrlSetData($Label1, IniRead("Config.ini", "General", "Label1", "This is the label 1!"))

;-->CODE


While 1
$nMsg = GUIGetMsg()
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit

EndSwitch
WEnd

If for some reason not able to read the key "Label1" in the "General" section, returns the value "This is the label 1!" If not, the value that is returned is of the configuration file.

Default is on failure (the file does not exist, or the key does not exist it returns default)

And not necessarily have to be in extension. "Ini". You can invent.

Edited September 20, 2012 by GordonFreeman

[Mechaflash]

As a side note, you may want to focus your efforts on XML, unless you want to mess with existing .ini's. It seems that is what modern programs are using where they used to use ini files.

To add to Dictator's post,

If your directives are not very complex, and do not need a hierarchy in order to keep it organized. INI files are just fine. 3 of my applications utilize INI files and they work without any issues. If you have many directives or require additional organization, XML is a better format.

Or if you just want to be one of the cool, new, hip kids, just use XML and say "INIs are for OLD PEOPLE"

[BrewManNH]

The only problem with XML is that they are far from as easy to use as ini files are. There's going to be a much steeper learning curve.

[StringingLong]

Forget about all the advice about XML for now. It will only confuse you.

Master this first, and then you can move onto more complex strategies as your program design goals deem fit.

Storing and retrieving data from an INI file is trivial.

What Is An INI File?

An INI file is a text file that is represented in easy to read human format. It consists of sections whose names are encapsulated in "[" and "]" brackets. Within each section are key = value pairs.

For example::

myini.ini

---------------------

[Options]

maxLines=40

screenWidth=800

screenHeight=600

[user]

admin=Joe

In this example, there are two sections - User and Options.

Within the section are key/values that are associated with the section.

In the key/value pair, admin=joe, admin is the key and joe is the assigned value

In the key/value pair, maxLines=40, maxLines is the key and 40 is the assigned value

How To Read And Write An INI File

INI files store data. They are a quick way to do so without much programming effort. They are not ideal if you have lots of data to reference. As the size of the file grows, it takes longer to find and insert things. So using INI files is not ideal for really large data sets - you should use a database instead.

To retrieve data and write data in an INI file, you use the IniRead and IniWrite functions.

First thing you want to do, is create one by hand with your text editor and put in default data. Give it a filename and then save it to the same dirctory as your AutoIt program.

Lets take an example. Suppose your AutoIt app has a need to store the screen width, screen height, and admin name.

If you need to get at the data specifically, you do this:

$screenWidth = IniRead("myini.ini","Options","screenWidth",640)
$screenHeight = IniRead("myini.ini","Options","screenHeight",400)

If you need to save the new screen height into the myini.ini file, you do it like this:

IniWrite("myini.ini","Options","screenHeight",480)

Is that really hard? This is as simple as it gets to storing data into a file.

Edited September 21, 2012 by StringingLong

[rudi]

Hi.

readup in the help file:

iniread()

iniwrite()

inireadsectionnames()

inireadsection()

iniwritesection()

inirenamesection()

ini...()

;-)

#include <array.au3>

$ini="C:Documents and SettingsmasteraccountDesktopFutureControlPannel.ini"
$Section="WORKSTATIONLIST"

$IniSection = IniReadSection($ini,$Section)
_ArrayDisplay($IniSection,$IniSection[0][0])

$txt = "Section " & $sect &@CRLF
for $i = 1 to $IniSection[0][0]
$txt &= $IniSection[$i][0] & " = " & $IniSection[$i][1] & @crlf
Next

MsgBox(0,"content",$txt)

And: Perhaps you might want to let us know, what's your task about?

Regards, Rudi.

Edited September 21, 2012 by rudi

[guinness]

All,

These are some of the examples from the latest alpha version of AutoIt. Do they better demonstrate the functions? Let me know.

IniRead:

Example()

Func Example()
    ; Write the value of 'AutoIt' to the key 'Title' and in the section labelled 'General'.
    IniWrite(@ScriptDir & "Example.ini", "General", "Title", "AutoIt")

    ; Read the INI file for the value of 'Title' in the section labelled 'General'.
    Local $sRead = IniRead(@ScriptDir & "Example.ini", "General", "Title", "Default Value")

    ; Display the value returned by IniRead.
    MsgBox(4096, "", "The value of 'Title' in the section labelled 'General' is: " & $sRead)

    ; Delete the key labelled 'Title'.
    IniDelete(@ScriptDir & "Example.ini", "General", "Title")

    ; Read the INI file for the value of 'Title' in the section labelled 'General'.
    $sRead = IniRead(@ScriptDir & "Example.ini", "General", "Title", "Default Value")

    ; Display the value returned by IniRead. Since there is no key stored the value will be the 'Default Value' passed to IniRead.
    MsgBox(4096, "", "The value of 'Title' in the section labelled 'General' is: " & $sRead)

    ; Delete the INI file.
    FileDelete(@ScriptDir & "Example.ini")
EndFunc   ;==>Example

IniReadSectionNames:

Example()

Func Example()
    ; Create an INI section structure as a string.
    Local $sSection = "Title=AutoIt" & @LF & "Version=" & @AutoItVersion & @LF & "OS=" & @OSVersion

    ; Write the string to the sections labelled 'General', 'Version' and 'Other'.
    IniWriteSection(@ScriptDir & "Example.ini", "General", $sSection)
    IniWriteSection(@ScriptDir & "Example.ini", "Version", $sSection)
    IniWriteSection(@ScriptDir & "Example.ini", "Other", $sSection)

    ; Read the INI section names. This will return a 1 dimensional array.
    Local $aArray = IniReadSectionNames(@ScriptDir & "Example.ini")

    ; Check if an error occurred.
    If Not @error Then
        ; Enumerate through the array displaying the section names.
        For $i = 1 To $aArray[0]
            MsgBox(4096, "", "Section: " & $aArray[$i])
        Next
    EndIf

    ; Delete the INI file.
    FileDelete(@ScriptDir & "Example.ini")
EndFunc   ;==>Example

[Mechaflash]

@Guinness

I like how pretty much each line has a comment explaining what's happening.

me likes.

[guinness]

mechaflash213,

Everyone (including yourself) are welcome to re-write the examples and submit to the help file section of the Developer Forum, so long as they follow the similar structure presented above. I go on the basis that if a user asks a question (like above) and an example needs to be written in the Forum, then this is a good sign that the example in the help file is lacking something and thus should be re-written. Help file first, Forum second!

Edit: Typo.

Edited September 21, 2012 by guinness

[Mechaflash]

But then there's the fact that many people forgo the help file and ask for help in the forum... which is a common occurrence.

Maybe we should start a 'Help File Campaign' to raise awareness that a help file for AutoIt DOES IN FACT EXIST!

While learning about ini files, I don't think I ever asked any questions on it. The help file was pretty self-explanatory.

Then again, it's human nature to not want to EVER fail at anything... so instead of taking the leap and just playing around with the functions to find out what they do, the cautious question is asked.

Even if the documentation is extremely accurate and informative, there will still be people who want another being's input on the subject before they take action. <---- I've come to learn that these people are hated by the programming community.