Thanks for the inputs guys. This is where I am wrong assuming that assuming I can write Cpp just like I write Python.
So let me explain you the root of the problem so maybe someone has an idea how to solve it with another way. We have a solver in Cpp (for optimization purpose). This solver needs to be initialized with some values that only need to be computed once. We did a prototype in Python and it works just fine. The init values is just a bunch of list of strings, integers and floats. Nothing weird. Rather than rewriting this whole initial computation in Cpp, which would take us a lot of time (and is using some external python libraries), we though we could just do the init in Python store the result in a datablob and read this from the Cpp solver. What would be the best way to ready array of strings, integers and floats stored somewhere in the scene from a Cpp solver ? thanks for your help ! Jeremie On 3 February 2014 18:25, Alok Gandhi <[email protected]> wrote: > 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. >> > > > > -- >
