SDK - DLLVarHandler. Bug or Feature?

[JTaylor]

I found a use for DLLVarHandler and it works great other than a problem that I am not sure if it is a bug or not.

If I create and write out an Array it works great.   

If I read back in the same array it works great and I can read the data as expected.

If write back out that same array it becomes corrupted.  There are no errors.   DLLVarHandler() reports success.

This doesn't happen with other data types such as STRINGs and INTs.  I can read back and write back repeatedly.   I have tried overwriting the Array with an INT and then writing over that with the array.  I have tried clearing the Array and then writing it back out.

I know you have better things to do and if you don't want to bother with it just let me know but thought I would ask in case it was a bug...plus it would be very helpful in the SQLite project if I could make it work.

Thanks as always.

Jim

[td]

There are no known issues with DLLVarHandler. Assuming you are referring to WIL arrays, they are handled like any other basic WIL type.  The value you pass in is assigned to a variable verbatim.  DLLVarHandler is very simple in that all it does is assign the array memory reference and type to a WIL variable structure.  It never touches array data. Of course, unlike other WIL data types, arrays are just a memory reference in WIL variables so any corrupting you do to the array data structure will be reflected in the WIL variable.

[JTaylor]

I would assume it is a given that if I write a corrupted array to WIL that it isn't going to magically fix it.   That is my point/question.   I successfully write out to WIL and it works and I then read it back in and it is fine.  I can read to my hearts content within the extender.   If I write that same Array back out to WIL, without doing anything to it, it no longer works.

I am successfully using this on a variety of fronts so I am fairly sure I am doing it "right".  Always the chance I am missing something, of course, but since I am using the same code that works the first time, that shouldn't be the case.  In addition to all the other things I have tried.

Just thought I would mention it as you would have said there were no known issues with the other problem I found as well.  I really am trying to not bother you with questions or trivialities that I don't feel have merit.

Jim

[td]

You are making several assumptions that are simply not true when it comes to the world of C++ programming.  Also, the extender function in question has been tested and works when used correctly.  In this case, your description of what you are attempting to do has several possible interpretations.  One of those possible interpretations suggests that you are writing over the top of an array reference instead of just modifying the array pointed to by the reference.  Not saying that this is what you are doing because what you are doing is unclear but it is one of several interpretation that could explain the behavior you are seeing.

[JTaylor]

You interpreted correctly.  I misunderstood how this was working.  This was very helpful.  Thank you and sorry for bothering you again.

Jim