Jump to content

Rewrite INI-Functions


Xenobiologist
 Share

Recommended Posts

Hi @all C/C++ freaks,

there is a feature request which could be done by YOU! :D

Link : http://www.autoitscript.com/trac/autoit/ticket/15

Anybody who wants to develop the code and submit it to the devs, so that they "only" need to review it?

This is a very encapsulated topic which enables the possibility to work on by some "non-standard-dev".

I would do it myself, but I'm no c/c++ geek. :D

I hope there is a volunteer for this, because ini functions are used very often and e.g. the 32K border sucks.

Mega

P.S.: If the devs don't like this, then just lock the thread or delete it. THANKS!

Scripts & functions Organize Includes Let Scite organize the include files

Yahtzee The game "Yahtzee" (Kniffel, DiceLion)

LoginWrapper Secure scripts by adding a query (authentication)

_RunOnlyOnThis UDF Make sure that a script can only be executed on ... (Windows / HD / ...)

Internet-Café Server/Client Application Open CD, Start Browser, Lock remote client, etc.

MultipleFuncsWithOneHotkey Start different funcs by hitting one hotkey different times

Link to comment
Share on other sites

If I'm allowed to comment.

It would be really interesting to see this happening. Further developing feature that is recommended to be left behind. As much as it is their discretion right it would be a real waste of resources.

Ini-matic should be left where it belongs - 20th century.

♡♡♡

.

eMyvnE

Link to comment
Share on other sites

I agree with trancexx. Instead of spending valuable time on a deprecated feature (that should only be left in for legacy reasons) the time could be spent on something much better, like say XML instead.

Ini files are part of the past. I wonder when AutoIt users get that.

Broken link? PM me and I'll send you the file!

Link to comment
Share on other sites

Well, so trancexx doesn't like the idea of working with ini or property files. OK! I like code which is data-driven and not hard-coded.

But that is not the point of this thread!

The point is, why should the devs develop all the code alone? When there is a closed functionality, somebody else could give it a try.

The concept works for udfs, why not for Autoit internal code?

So please, if you want to participate in developing Autoit and you are able to develop the ini functions as described in the thread, then please do so.

Mega

Scripts & functions Organize Includes Let Scite organize the include files

Yahtzee The game "Yahtzee" (Kniffel, DiceLion)

LoginWrapper Secure scripts by adding a query (authentication)

_RunOnlyOnThis UDF Make sure that a script can only be executed on ... (Windows / HD / ...)

Internet-Café Server/Client Application Open CD, Start Browser, Lock remote client, etc.

MultipleFuncsWithOneHotkey Start different funcs by hitting one hotkey different times

Link to comment
Share on other sites

Yeah, officially .ini files are deprecated but they are used heavily by all sorts of programs, for example bleeding-edge-of-technology games. It's selfish to declare any work on that huge aspect of windows a waste of time.

Don't take this the wrong way, but I suggest those that aren't interested to just leave the thread alone. It'll die off unless someone with the skills+time+interest comes.

(Or if Valik calls us all inbred morons and locks it anyway :D )

Link to comment
Share on other sites

Well, so trancexx doesn't like the idea of working with ini or property files. OK! I like code which is data-driven and not hard-coded.

But that is not the point of this thread!

Huh? Who's talking about hard coded stuff? All I'm saying is ini files are a thing of the past and newer more efficient data formats available that rest of the world has accepted as standard. Example: Are you still saving your images in bitmaps and your sound files in wav files? If not, do explain.

The point is, why should the devs develop all the code alone? When there is a closed functionality, somebody else could give it a try.

The concept works for udfs, why not for Autoit internal code?

Because AutoIt is not open source. If the developers wished that everyone and their grandmas submitted source to the core they would have put an open source license on it.

Yeah, officially .ini files are deprecated but they are used heavily by all sorts of programs, for example bleeding-edge-of-technology games. It's selfish to declare any work on that huge aspect of windows a waste of time.

So? Most anti-virus claim to use cutting bleeding edge technology while in fact they mostly is the biggest pile of shit you can find.

Also, ini-files used 15 years ago aren't a waste of time, they were standard then.

I (hopefully) don't have to explain why ini-files sucks, because everyone who think can figure it out. For those who can't, google is available for free of charge.

Don't take this the wrong way, but I suggest those that aren't interested to just leave the thread alone. It'll die off unless someone with the skills+time+interest comes.

Why? The only thing that makes me posting in this topic is that I want autoit to be the best it can be. I'm also trying to save some poor sob a great deal of work.

A closing word, you guys are always whining about autoit not being able to reach the wider masses. This is exactly why, the brutal raping I have seen of the ini format on this forum could scare even the nuttiest coder away. I mean, what you guys want to save in ini files that are >2^15 bytes long are truly beyond me.

For once, try to evolve, try to see out of the tight little bubble you have build around yourselves. Try to realize that autoit is not the end tool for everything and ini files are not the mother and god of all data formats. Try adapting some of the standard, thinking and languages rest of the world uses. It would not only make your program and coding better and more efficient, it will also increase your understanding of autoit and maybe even to such a degree that you might even do a valuable submission to the language.

Awaiting storm.

Broken link? PM me and I'll send you the file!

Link to comment
Share on other sites

The only thing I find... interesting... about the ini functions is that they do not accept file handles... I never understood that, but then... I have no Idea how they made the functions in the first place.

; testing ini functions
$sIni = @ScriptDir & "\example.ini"
IniWrite ($sIni, "test", "value", "WORKS!!!")

MsgBox (0, "Testing unopened ini file", IniRead ($sIni, "test", "Value", "DOESN'T WORK!!!"))  

$hFile = FileOpen ($sIni, 0)
   MsgBox (0, "Testing Opened ini file", IniRead ($hFile, "test", "Value", "DOESN'T WORK!!!"))
FileClose ($hFile)
FileDelete ($sIni)
If anyone is going to rewrite them, can that be considered? There are times i'm calling 5 - 10 inireads in a row, from different sections, and thats where opening them would be a good idea. I'm not an expert, AutoIt is my first and main language, so If this post was nonsense ignore it :D

Mat

Link to comment
Share on other sites

I don't entirely agree that INI files are obsolete. I quite like them because they are quick and easy. They are easier and faster to work with (both from the human standpoint and the machine standpoint) than XML. INI is still human editable but XML is not as much. It's too easy to make a mistake that'll make the XML completely unparsable. XML is useful for complex data sets where-as INI is better for simple data sets or data that needs to be human editable. In other words, there are pros and cons to both INI and XML and like with everything else the choice of which one should be used should change on a case-by-case basis.

Here's the problem with some random person trying to submit something like an INI rewrite to AutoIt: Me. Only I really know what I want to see out of an INI parsing class. Chances are, somebody who wanted to contribute would sit down, rewrite the existing INI functions and think that's good enough. It's not. I want a class that encapsulates all the INI functionality. I want it to be well written and I want it to do things I probably haven't commented on in the ticket. If anyone knows of an existing class with a permissible license I could use as a building block to do what I want, that's fine. But otherwise, this isn't really something some random person can do without a ton of feedback from me on exactly what I want. Then, depending on the competency of that person, it might be more work explaining what I want than doing it myself.

Lastly, there's been a bit of a misunderstanding. My response on the ticket was not an open invitation for anybody to write the feature. It was simply to demonstrate that delegation is not how things work around here. We volunteer to work on the features we want. We don't sit around assigning things to one another beyond the broad scope that Gary handles UDF stuff, Jon handles AutoItX and Jos handles SciTE/Au3Check/All the stuff that comes with SciTE4AutoIt3. Beyond that anyone is free to work on whatever they want.

Link to comment
Share on other sites

The only thing I find... interesting... about the ini functions is that they do not accept file handles... I never understood that, but then... I have no Idea how they made the functions in the first place.

We use the Windows API.

; testing ini functions
$sIni = @ScriptDir & "\example.ini"
IniWrite ($sIni, "test", "value", "WORKS!!!")

MsgBox (0, "Testing unopened ini file", IniRead ($sIni, "test", "Value", "DOESN'T WORK!!!"))  

$hFile = FileOpen ($sIni, 0)
   MsgBox (0, "Testing Opened ini file", IniRead ($hFile, "test", "Value", "DOESN'T WORK!!!"))
FileClose ($hFile)
FileDelete ($sIni)
If anyone is going to rewrite them, can that be considered? There are times i'm calling 5 - 10 inireads in a row, from different sections, and thats where opening them would be a good idea. I'm not an expert, AutoIt is my first and main language, so If this post was nonsense ignore it :D

Mat

INI files (via the Windows API) are buffered. In theory multiple writes won't cause an open - write - close sequence every single call. In reality, AutoIt flushes after every write so it does do that sequence every call. This is part of the trade-offs we have to make of performance versus simplicity. We could certain not flush the file after every write and leave that up to the scripter, but then we'd be fielding questions on why INI files aren't being updated.
Link to comment
Share on other sites

Thanks for all your answers. Valik I think you answer is fair. It is your code and I understand that you want it the way you like it. No problem!

So, as mentioned in my first post. If there is a problem with the idea that somebody else helps to write Autoit fnuctions then lock the thread and all is fine.

I'll give FileRead and Stringsplit and so on a go until the functions work with content bigger than 32K.

P.S. : I totally agree that there are pros and cons concerning the use of ini files. (like mentioned by Valik) nevertheless they are quite useful.

Mega

Edited by Xenobiologist

Scripts & functions Organize Includes Let Scite organize the include files

Yahtzee The game "Yahtzee" (Kniffel, DiceLion)

LoginWrapper Secure scripts by adding a query (authentication)

_RunOnlyOnThis UDF Make sure that a script can only be executed on ... (Windows / HD / ...)

Internet-Café Server/Client Application Open CD, Start Browser, Lock remote client, etc.

MultipleFuncsWithOneHotkey Start different funcs by hitting one hotkey different times

Link to comment
Share on other sites

INF files are still used for device drivers and other descriptions.

INI, INF, SIF files (at least in XP) are used greatly to define the boot sequence of the OS. Working with XPE recently, I found they are everywhere.

Post your code because code says more then your words can. SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=Y. Use Opt("MustDeclareVars", 1)[topic="84960"]Brett F's Learning To Script with AutoIt V3[/topic][topic="21048"]Valuater's AutoIt 1-2-3, Class... is now in Session[/topic]Contribution: [topic="87994"]Get SVN Rev Number[/topic], [topic="93527"]Control Handle under mouse[/topic], [topic="91966"]A Presentation using AutoIt[/topic], [topic="112756"]Log ConsoleWrite output in Scite[/topic]

Link to comment
Share on other sites

(Indirect Holler for a moment, normal service will resume shortly)

horrible cliche coming "Oooh thats soooo 20th Century" (post 2) :D

Lets think about that comment for a moment, The person making this statement is basically griping that something was conceived within the time span of the last 100 Friggin years, a comment made ever lamer by the simple fact that we are only 9 (count em) years into the 21st Century.

Xml : first draft was in 1996

SQL : first commercial sql based product was released in 1976

CSV: could not find a creation date but the format dates way back.(And can be used loosely in Ini format anyway.)

Dropping of the Ini format in favor other formats!? well hell those are smart words. (blimey is that a snowflake I see) :D

Ini files remain widely in use today (and will for a good while yet) for 2 simple important reasons specified in post 11.

I am all for updating the Ini format (love it in fact), but surely such an update could be done via dll just as easily as tampering with the grail. :D

You have to admit that 32kb is quite large for a config file.

Vlad

Edited by Mobius

wtfpl-badge-1.png

Link to comment
Share on other sites

(Indirect Holler for a moment, normal service will resume shortly)

horrible cliche coming "Oooh thats soooo 20th Century" (post 2) :D

Lets think about that comment for a moment, The person making this statement is basically griping that something was conceived within the time span of the last 100 Friggin years, a comment made ever lamer by the simple fact that we are only 9 (count em) years into the 21st Century.

Xml : first draft was in 1996

SQL : first commercial sql based product was released in 1976

CSV: could not find a creation date but the format dates way back.(And can be used loosely in Ini format anyway.)

Dropping of the Ini format in favor other formats!? well hell those are smart words. (blimey is that a snowflake I see) :D

Ini files remain widely in use today (and will for a good while yet) for 2 simple important reasons specified in post 11.

I am all for updating the Ini format (love it in fact), but surely such an update could be done via dll just as easily as tampering with the grail. :D

You have to admit that 32kb is quite large for a config file.

Vlad

You are projecting (again).

Would someone be kind to give the definition of the INI file?

@bo8ster, you are mentioning device drivers. Nice touch.

♡♡♡

.

eMyvnE

Link to comment
Share on other sites

You are projecting (again).

Would someone be kind to give the definition of the INI file?

@bo8ster, you are mentioning device drivers. Nice touch.

Although there is a difference have a look at :

http://en.wikipedia.org/wiki/.properties

http://de.wikipedia.org/wiki/Initialisierungsdatei

Sometimes it is used like a key value hashmap. Which could be used in Autoit e.g. with Dictionary object.

You can easily read info from it. Just ask for the key and get the value. The parsing is done internally.

It can be read and changed by human without all the overhead needed for xml.

Mega

Scripts & functions Organize Includes Let Scite organize the include files

Yahtzee The game "Yahtzee" (Kniffel, DiceLion)

LoginWrapper Secure scripts by adding a query (authentication)

_RunOnlyOnThis UDF Make sure that a script can only be executed on ... (Windows / HD / ...)

Internet-Café Server/Client Application Open CD, Start Browser, Lock remote client, etc.

MultipleFuncsWithOneHotkey Start different funcs by hitting one hotkey different times

Link to comment
Share on other sites

Why do the ini files need to be reimplemented as a C++ class? Can't we use AutoIt for this stuff by now? An ini UDF seems like a good idea to me. That would bring much more versatility, because we can actually modify the Au3 at a basic level, whereas the C++ can not be modified.

By that logic a lot of functions can be rewritten in native AutoIt. But since the ini functionality is going to be rewritten anyway, why not in AutoIt?

Link to comment
Share on other sites

If we begin porting things out then where do we draw the line drawn?

I think this is all a moot point. The INI stuff isn't even on my radar. Debating on the merits of C++ versus AutoIt or INI versus other formats is all academic really because things aren't going to change anytime soon.

Link to comment
Share on other sites

If we begin porting things out then where do we draw the line drawn?

Porting things out is not something bad in itself. Being against porting out would be like saying that the AutoIt developers never make a mistake. (Which I'm sure you don't do; but what about the other dev's?). A line doesn't always need to be drawn from the get go.

But this is just a generalization. I'm purposely letting out important details, like performance loss and backwards compatibility.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...