Leaderboard

This happens, for example, if the .ini file was saved in an UTF-x format (character encoding) with BOM (Byte Order Mark). The Byte Order Mark is placed (not always visible in all Text editors, but in a Hex-Editor) at the beginning of the file. If the first line of the ini.file is a section, e.g. [Section1], then the BOM will be inserted before [Section1]. As a consequence, IniRead no longer recognizes this line as a valid section and associated key/values will be ignored. Just for information : BOM headers Hex : EF BB BF (Decimal : 239 187 191) -> UTF-8 Hex : FF FE (Decimal : 255 254) -> UTF-16 Little Endian Hex : FE FF (Decimal : 254 255) -> UTF-16 Big Endian Solution (as already suggested by @Subz ) : Open the .ini file in e.g. Notepad++ and change the encoding to ANSI -> save it.

AutoIt v3.3.16.1 has been released. Thanks to @jpm and the MVPs who were responsible for the majority of code in this version. Download it here. Complete list of changes: History

@TheDcoder is right (as almost always ). AFAIK IniRead based on the Windows function GetPrivateProfileString (A/W ?) from the Kernel32.dll and is capable of processing both ANSI and UNICODE. The problem with parsing an .ini file is just the Byte Order Mark at the beginning. For example, if the first line is a comment, such as ; My ini file V 2.1.5 [Section1] Key=value ... then the [Section1] will be read without any problems, because the comment line starts with the BOM and will be ignored anyway. In general, however, a Byte Order Marking is not a negative feature, as it allows the character encoding to be determined unambiguously. With ANSI and UTF-8, for example, this is not so easy.

That's not true, AutoIt can handle Unicode. The INI parser in AutoIt just has trouble if there's a BOM.

Yes, I know, I know both things. But so far I have only used 1D and 2D arrays, with simple (integer / string) values. Never array inside array. And I didn't know how to access the values of the "smaller doll" inside the "big doll" !! But I have found the solution and edited my original post. Thanks.

Will have look at that as I thought I changed something there before my vacation.

Jos, Just to offer another point of view: I have been using the latest version for the past week and I am very satisfied with the way the autocomplete list is currently working. Steve G

I have had an issue with the first section of an INI file on a few occasions. It has proved to be how the text file was created in the first place or updated not using INI functions. Using _FileCreate or _FileWriteToLine for instance can cause this issue. From what I recall it is a UTF8 and BOM issue ... some ANSI thing. EDIT - IT would appear Musashi has the right of it in better detail than my explanation.

Please delete this token ASAP or get ready to have your account hacked. Just make a new one and don't post it anywhere.

From the help file I think it should be (scroll down for the code examples): opt ("TrayAutoPause",1)

What's New in Version v1.9.5 (and v1.9.6) - Added 2 new algorithm-specific functions. _CryptoNG_AES_GCM_EncryptData _CryptoNG_AES_GCM_DecryptData Added an AES GCM example to the examples file. Added AES GCM functions to the Help File. Optimized some internal functions Updated the supplied calltips and userudfs files. Misc function header corrections/modifications v1.9.6 _CryptoNG_AES_GCM_DecryptData Added an explicit Authorization Tag length validation. ( @error = 8 ) Updated the function's help file entry to reflect the new @error (8). Slightly modified the AES GCM encrypt/decrypt example to make the return values from the encryption, which is an array, more explicit and easier to understand.

Unfortunately, without a compelling reason, I have no intention of doing any pull requests or otherwise doing any of your scripting for you. You're welcome anyway... If you are interested in learning more about jq and how to use it, I may be willing to help you with that. If it takes your script 20-30 seconds to build your array using json.au3 functions and it only takes 0.5 seconds to build the same array using jq, then it might be worth taking the time to learn how to use jq. JSMN (json.au3) is a great JSON parser. jq is a great JSON processor. Generating a tab-separated-value list of all of the data needed to build the array is done in a single function call to jq, which returns its result in well under 0.5 seconds (it took an additional 0.1 seconds to convert the TSV list to an array which came to a total elapsed time of just over 0.5 seconds). Your current way is to loop through the 1900+ array objects, with each object containing 15 key/value pairs, doing over 29,000 json_get() calls in order to parse and put each individual value into your array. I think it is pretty clear why your way takes considerably longer (20-30 seconds) to generate its result. This was an excellent example of the difference between JSON parsing and JSON processing. It was also an excellent example of how using the right tool(s) for the job can make a HUGE difference!

@Mateocedillo I took a quick look at your _FakeYouGetVoicesList() function. I'm not sure how long your functions takes on your test PC's but, I have written a function that creates the voices array in a little over half a second on my PC. My array includes all of the values in each model, just like your function. Output: Time to create array: 0.518 seconds Number of rows: 1941 Number of cols: 15 My script uses jq to create the array because I think it is better suited for this particular task. Since I think discussing alternative solutions in detail, in someone else's topic is rude, I will not go into detail on how I did it here. If you want to see suggestions on how it could be done using jq, then I would suggest that you create a new topic with any questions that you may have related to using jq. If you want to stick with the json.au3 UDF, then there are several ways to speed up your function. Since none of these suggestions have anything to do with the json.au3 UDF itself, and the fact that your issues have nothing to do with the json.au3 functionality, I'm not sure that this is the right topic for a detailed discussion on how it could be done. So without going into detail, I will just list a few items/questions for you to think about in terms of speeding up that function: Do you really need an array at all? Basically you are moving all of the data from one structured format (json/dictionary) that can be queried to another one (variant array), that seems totally unnecessary and time-consuming. Do you really need to have all of those values in your array? If you don't need or use values like create_at/update_at/etc, why take the time to move them to a separate array? Working with arrays and strings are 2 of the slowest processes you can do in AutoIt. The fewer execution of array and string functions you need to create your array, the faster that process will be.