I'd side with exactly what Matt and Oleg are saying, the data stored in a
user data blob through C++ is essentially binary. That might be the cause
of the issue. I wrote some plugin for userdatablob using c++ but I was
writing the data instead of reading it. You can probably do the inverse of
what I did.
Here is the code from my plugin:
----------------------------------------------------------------------------------------------------------
struct DataForBlob
{
const char* blobVal;
} ;
DataForBlob blobData; blobData.blobVal =
CString(L"MSVDATA").GetAsciiString(); UserDataBlob blob ;
agentModel.AddProperty( L"UserDataBlob", false, L"msvResource", blob);
blob.PutValue((unsigned char*)&blobData, sizeof(blobData)) ;
blob.SetLock(siLockLevelAll);
--------------------------------------------------------------------------------------------------------
On Mon, Feb 3, 2014 at 9:15 PM, Oleg Bliznuk <[email protected]> wrote:
> casting from char* to CString* is unsafe as you dont know how CString is
> implemented. It can be even not null-terminated ( and most likely this is
> true as its responsible to hold both wide and non-wide characters ) inside
> and in such case the "LogMEssage" internally may call something like
> "GetLength() {return m_Length;}" but physically there is only
> null-terminated char buffer or whatever JSON stuff can holds. First check
> if the "x" is not NULL after GetVall call and then try to create CString
> stringObj ( x ) and log it.
>
--
