In checking a few of my apps I found one that uses your Kaju (which I appreciate very much.) It has 18 places where “JSONitem” is used, 17 are within the Kaju class.
Should I change all 18 to use "JSONitem_MTC?
Thanks again you and Luke and Jeremy Cowger for KAJU.
The JSON in Kaju is well controlled and fairly small, and speed is not a big issue, which is why I didn’t use it there. I’d leave that alone.
I just released JSONItem_MTC v.4.0. While there have been no functional changes to that class, the project now includes M_JSON, and that includes ParseJSON_MTC and GenerateJSON_MTC. As you might guess, those do what the new framework Xojo.Data. functions do, but with the classic (soon to be API 2.0) framework. In other words, rather than working with Text, Xojo.Core.Dictionary, and Auto(), they work with String, Dictionary, and Variant().
GenerateJSON_MTC also has an optional parameter to produce “pretty” output.
As always, the project can be found at:
The JSONItem_MTC project has been update to 4.1. This is a minor change that only affects debugging. When the keys of JSON objects are stored internally, they used to be converted to/from hex to preserve case-sensitivity. Now they are stored in the form key-HEX.
This is really fantastic Kem! I had the same problem and you solved it!
Thank you for sharing your hard work!
Tim
I’ve updated the project to 4.1.1. It turns out that M_JSON was not encoding embedded quotes or backslashes, a mistake so embarrassing that I wish @Thom McGrath had caused it instead of merely reporting it. Alas, I am left with nobody else to blame, and hope it didn’t cause any headaches.
Again, the project is at:
[quote=263359:@Kem Tekinay]JSONItem_MTC , the drop in replacement for the classic framework JSONItem
If you’re using JSONItem, I encourage you to consider this instead.[/quote]
I’ve been using JSONItem_MTC in a project, and noticed the speed improvement. So thanks a lot!
In another project it seems I have run into a limitation, which doesn’t make JSONItem_MTC a “drop in replacement” 
It seems that JSONItem_MTC can’t handle Array-Values 
Here is an example project showing the issue/difference.
This works as expected with JSONItem:
Dim oJSON As New JSONItem
oJSON.Value("field") = "a_fieldname"
oJSON.Value("operator") = "IN"
oJSON.Value("values") = Array(12, 15, 20)
JSONItem_MTC however raises a JSONException( "Illegal Value", 10 ).
One could modify it’s .Validate to cope with Arrays (get the DataType of the Array-element-type -> TypeArray is logically OR’ed with the element type):
Dim iCheckVariantType As Integer = Bitwise.BitAnd(value.type, Bitwise.OnesComplement(Variant.TypeArray))
select case iCheckVariantType
But then .Serialize -> .EncodeValue will fail.
That’s why I’ve stopped trying the do further modifications… at least before asking if you intend JSONItem_MTC to handle Array-values sooner or later?
Picky, picky, picky…
Please pull the latest develop branch of the project. It includes unit tests to show what works for JSONItem_MTC now, and what does and doesn’t work with JSONItem.
https://github.com/ktekinay/JSONItem_MTC
Edit: Bolded the word “develop”.
I just ran this against my develop branch without issue. What am I missing?
Be sure you’re on the develop branch as Kem mentioned.
https://github.com/ktekinay/JSONItem_MTC/branches
Norman’s deleted post contained code that doesn’t work on the current release version, but does work on the develop branch that contains that fix. I’ll release it as soon as I am comfortable that it now works correctly and matches (or, in this case, exceeds) the native version.
I’ll do that in the next couple of days.
I haven’t even thought about looking into the other branches beforehand… but it seems that you’ve checked in a fix after my last post and not have done that work long ago with me not finding it (by not looking into the dev-branch).
Yeah - sorry about that 
It might have been worth being picky, if that has helped to improve JSONItem_MTC even more. 
Anyway - thanks a lot for the fix! I’ll see how it works for this project when I get back to it.
Maybe I should have put a 
after “picky, picky, picky”. Text doesn’t always get the meaning across.
The current fix was entirely due to your post, in case that wasn’t clear.
Not when I’ve only read that one first
Ah… now I see, that’s related to a deleted post.
At least I have put a couple of after quoting your 3x picky - I think it has been clear enough
Thanks again…!
Yeah, unfortunately Norman deleted his post so the responses are now out of context. That was in response to code he posted that he claimed still didn’t work, but I’m pretty sure he tried it against the release (master branch) instead of the just-fixed develop branch.
Anyway, let me know what you find. Since this class has been out literally for years without anyone noticing, I guess I can wait another few days to make sure the fix is right.
I removed my comment based on the complaint I received about the impression it might have left readers with
Someone is always the first one… Even though I can hardly believe no one seems to have been using Array-values.
So far it now works as a “drop in replacement”
And should this project uncover other picky issues, I’ll let you know. So far - all good. Thanks!
It’s not that nobody was using array values, it’s probably that they, like me, were creating a new instance to hold the array.
Ah right - I’ve taken a shortcut then
Picky again…?
There’s a typo here: raise new JSONException( "This JSONItem_MTC is an obect", 13 )
And another one in the release notes of the Dev-Branch: JSONItem_MTC will roperly deal with assignments of arrays.
Fixed, thanks.