I purchased the ActiveX bundle and am trying to parse JSON text. It throws an error loading the .jsonObject in Visual Foxpro and it does not appear to be listed in the registry.
loObject = CreateObject('Chilkat_9_5_0.JsonObject')
Is there another DLL that I must register to get this feature?
The JSON functionality will be in the next Chilkat version release (in early March).
Here's a pre-release for testing:
Thanks! I'll give it a try.
When do you Think to release the DLL with Json for ActiveX?
I can create object Http, HttpResponse,... but I can't create
Chilkat will officially begin the v184.108.40.206 release in approx. 6 days.
Here's the very latest pre-release:
The online reference documentation and examples are already published..
I did some quick testing of Json for VC++ and have the following recommendation for improvement. While creating a complex structure, I will often have to call json.AddObjectAt(-1) or json.AddArrayAt(-1, "node name") and then immediately after a call to json.ObjectAt(json.get_Size() - 1) or json.ArrayAt(json.get_Size() - 1) in order to get a pointer to the newly added object or array.
This clutters up code unnecessarily and it would look much nicer if AddObjectAt() and AddArrayAt() returned a pointer to the newly created node, e.g. CkJsonObject AddObjectAt(int index, const char name).
Even returning the index of the created node would improve performance slightly, so that I can used that index in the next call as opposed to the repeated calls to get_Size(). I would prefer the pointer behavior though.
Since index will often be set to -1 for appending, it might also be a good idea to change signatures to e.g. AddObjectAt(const char name, int index = -1), so that -1_ becomes the default value and does not have to be specified explicitly. Alternately add another method _AddObject(const char name) or perhaps better AppendObject(const char *name).
I understand if the choices were made due to limitations in some programming languages, but otherwise these ammendments would make the class a bit easier to work with.
I hear you, but I wanted to avoid the same problems experienced with the CkZip object. In that API, there are methods such as AppendString, AppendData, etc, which return a CkZipEntry * object. The problem is that countless developers would call the method like this:
zip.AppendString("test");And this created a memory leak -- because AppendString returns a CkZipEntry object. So I wanted to avoid the same mistake which generates a lot of support email from programmers claiming the Chilkat leaks memory..
Also, it may be that a program doesn't care to receive the new item that was added, and it's more efficient to not return anything, and then only get it if needed.
As time goes on, I'll think about adding features to make the API better, but it's best (for now) to let it burn in a bit before making decisions I'll have to live with for a long time. :-)