Is it a Good Idea?: @error when key is not found in IniRead

[TheDcoder 744]

Hello , I was thinking of a situation where a key in a ini file can contain anything, If we were to know if the key does not exists using IniRead, Its not possible to do it without compromising a single possibility... I was thinking that if IniRead were to set @error when a key does not exist, it solves the problem which I mentioned before

 

What do you think? Would you like this feature?

TD

[BrewManNH 1,178]

The way IniRead works, if the key doesn't exist, then the default value is given. If the key exists but is blank the return value is an empty string. I think that using the Default Value as the check to see if the key exists should probably be sufficient.

[TheDcoder 744]

But it wouldn't hurt to set @error to non-zero!

[czardas 1,204]

Define error in this situation. Is it really an error?

[TheDcoder 744]

Define error in this situation

Key not found in INI file

[czardas 1,204]

And why is that an error?

[TheDcoder 744]

Isn't the non-existence of the key an error itself?

[czardas 1,204]

In most cases, the non-existence of an ini file is not an error.

[TheDcoder 744]

, maybe @extended in that case?

[czardas 1,204]

This is the way I see this - if I'm wrong then someone will most likely correct me. If a program starts and no ini file is found, then default settings are applied. As soon as you change some default settings, an ini file is created with the new default settings. Not all keys are necessarily included. Using ini files for different purposes is possible, but this is beyond the specifications as far as I'm aware.

[TheDcoder 744]

@czardas I agree , but we can use @extended as a indicator... or I can make a function to check if the key exists

[czardas 1,204]

Sure you could make this. I would set the default return value* to something strange and highly unlikely - a private range Unicode character would probably be a good choice. Or you could use a combination of strange characters if you are overly paranoid. Otherwise parse the file, but that's more complicated and probably slower.

* using the native function and checking the result: ==> one of several possible methods.

Edited December 10, 2015 by czardas

[TheDcoder 744]

@czardas Sorry for late reply, was too indulged in coding .  ...

[czardas 1,204]

Don't worry, I have things to get on with myself as usual. If you create this, let me know.

Edited December 10, 2015 by czardas

[TheDcoder 744]

[JohnOne 1,594]

I'd use this pseudo code...

Func _IniRead($File, $Section, $Key, $Default)
    Local $Return = IniRead($File, $Section, $Key, $Default)
    If $Return = $Default Then
        If Not _IniKeyExists($File, $Key) Then
            Return SetError(1, 0, $Return)
        EndIf
    EndIf
    Return $Return
EndFunc

Func _IniKeyExists($File, $Key)
    ;Logic
EndFunc

 

Edited December 10, 2015 by JohnOne

[guinness 1,483]

Ini files died 15 years ago!

[orbs 181]

TheDcoder,

without taking anything away from the perfect explanation by czardas, what benefit is there to you to know if a key exists or not? (other than the urge of being in total control over your program functionality, of course)

 

guinness,

the ini format, being as simple as can be, is still the best choice for some types of data storing - initial conditions of a program, to name one. besides, i don't recall MS publishing a death certificate for the ini specification... what MS do say, for example here, is that:

"This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry."

- which is an utter crap. sorry, but i can't find a more appropriate description. the place where an app should store its initial conditions is determined entirely by the nature of the app, not by any MS whim. i sure hope you do not follow that recommendation if you happen to design an app that needs its initial conditions in an ini file.

[guinness 1,483]

@orbs

XML, JSON, SQLite database, these are just a few of the better forms for storing data (configuration). Ini files are limited, hence why Microsoft used the registry. If I design an app these days, I use either JSON or XML for configuration storage.

[BrewManNH 1,178]

XML and JSON, yes...good for initial settings files even if a bit of an overkill for it.

SQLite database, way overkill if all you need it for is just to store some settings. Way too much overhead for something so trivial as that. Even if it would be a good way of doing it, who would want to go and learn how to use it just to store some settings when the INI format has been around for decades? It still performs the function it was designed for, even if it doesn't have Unicode support natively.