Could definitely use an example, thanks Alok. ;-)
On 4 February 2014 13:52, Alok Gandhi <[email protected]> wrote: > You could definitely write through python and read through CPP. You can > also read binary / ascii file on disk from CPP using streams if you want. > > I think your problem lies in reading the value in context of a CPP > operator. The way to access data from the input port is where you are > having a glitch, at least that's what I think. > > I am not near a machine right now so I cannot provide you with a specific > code. But I will do so later today or tomorrow in case somebody does not > answer before that. > > Sent from my iPhone > > On Feb 4, 2014, at 14:29, Tyler Fox <[email protected]> wrote: > > HI there, > I'm the Tyler that Jeremie was talking about in the original post. > > Writing the data generation in c++ is gonna be a really tough sell due to > time/knowledge/expertise constraints on this end. It's been a LONG time > since I've written any c++, and I'm doing some not easily portable stuff in > the python code. > > Would a possible workaround be to write a custom command that reads a file > on disk, builds my class structure using that data, and send that over to > my custom operator? > > Which leads to the question, is an operator's userData saved with the file? > > ~T.Fox > > > > > > On Tue, Feb 4, 2014 at 10:31 AM, Matt Lind <[email protected]>wrote: > >> Write it in CPP. >> >> >> >> If your data requirements are small, you can use a userdatablob template >> to store basic values to make them language agnostic (mostly). A template >> is essentially a customparamset applied to the object and flagged to be >> read by a userdatablob. Templates also exist for userdatamaps. >> >> >> >> >> >> Matt >> >> >> >> >> >> >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Jeremie Passerin >> *Sent:* Tuesday, February 04, 2014 10:28 AM >> *To:* softimage >> *Subject:* Re: [C++] Reading UserDataBlob as JSON String >> >> >> >> 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. >> >> >> >> >> >> -- >> >> >> > >
