Leaderboard

That's what I meant D:\Documents shows Documents (without any reference to D:). Unless you got full path displayed. To know if you are on D:\ drive (when not full path) you need to read the toolbar. No stress here. Just wanted to make a precision.

Introduction JSON is a pure data exchange format. Basically you only have to deal with JSON in 2 places in a program: Once when reading JSON data and once when outputting data. In between it should not really matter that the data used to be JSON or should be converted to it. You should not need any special intermediate structures but only the elements that the respective programming language provides anyway. This is exactly the approach of this UDF: There is the function _JSON_Parse(), which converts an arbitrary JSON string into (nested) pure AutoIt data types (Arrays, Maps, Strings, Numbers, Null, True, False). And on the other side we have the function _JSON_Generate(), which generates a JSON string from arbitrary (nested) AutoIt data structures. Import and export JSON So how to use - let`s give an example: Handling nested data structures JSON is often very nested. The resulting AutoIt data is therefore naturally also nested, which makes it somewhat cumbersome to process with pure AutoIt on-board methods. For this reason, the UDF comes with a few helper functions that make life with this data easier. One of them is _JSON_Get(), which allows you to access deeply nested data with a simple query syntax. On the other hand there is the function _JSON_addChangeDelete() with which you can (the name already says it) change, add and delete data. You can even easily create deeply nested structures with a single call. Again, here is a small example of how to use it: Strictly speaking, these functions should not even have "JSON" in their names, since they are generally applied to data structures in AutoIt. However, since they are often used in the JSON environment, we allow ourselves this small inaccuracy. Why should i give it a try? Probably the most common method to deal with JSON in AutoIt is the variant via JSMN. My minor dissatisfactions with this approach led me to write this UDF in the first place a few years ago. So the incentives are quite JSMN related: Parsing and extraction of data is faster than in JSMN. (Only if the JSON string makes heavy use of JSON escapes should JSMN be a bit faster in parsing, since the escapes are resolved later.) Editing the data is easier, because you don't need special commands for the JSMN intermediate structure but deal directly with AutoIt structures. Generating JSON is also simple: build your structure in AutoIt as you like and then let it generate a JSON string for you with _JSON_Generate(). The UDF is smaller (28kb vs. 45kb) The UDF is in pure AutoIt. You can directly customize any behavior as you like. >>sourcecode and download on github<<

That had performance reasons. With a classic ByRef, large strings have to be duplicated when they are transferred. As the function also works recursively, this would take place several times and would have a corresponding impact on performance. Important: “Would have”. In fact, AutoIt has quite obviously built in a kind of COW mechanism. This means that a copy is not created automatically, but only when the content is actually changed in the function. However, I do not know this with certainty but only deduce it from the performance behavior. The important point is: ByRef has no (more?) influence on the performance of the _JSON_Parse() function. So the recommendation would actually be to remove ByRef to enable direct string inputs. Which I have just done myself and adapted the repository accordingly.

argumentum, Simply "...'cause...I wanna...!"

Update Dlib to 19.24.4