> I'm in the process of writing a simple OCAF document browser. I can > browse the TDF_Label tree OK, but accessing the attributes is proving > tricky. Mostly, the problem is getting data out of OCC types back to > python. > > Can anyone suggest how to get the content out of a > TCollection.TCollection_ExtendedString ?
TCollection_ExtendedString.ToExtString() should do that though it seems that Standard_ExtString() isn't wrapped. That's why a pointer is returned that you can't access. As you know OCAF is a fairly new addition to pythonOCC, so thanks for pointing out these rough edges Bryan. All in all, we should have to jump through the hoops of the OCC API to get a simple string. At some point TCollection* and friends should be wrapped at the SWIG level, such that native python types can be used. Now that we've come to a point where all the modules that need to be wrapped are wrapped, its time to get some polishing done. > Also, converting Standard_GUID to a python value is difficult. I'd > like > to access the GUID as a string. To use the Standard_GUID::ToCString() > method, I need to pre-create a C-string (full of zeros), and pass it > in > by reference (as a Standard_PCharacter). Phew, C++ make things so > hard... Wow... pure torture... still impressive that you managed to do so, did you use ctypes? > Does SWIG give us any tools to construct types manually (from > ctypes objects perhaps)? Yes, I think what you're looking for is a swig typemap. Disclaimer: Thomas is the SWIG guru, so I could be really off... http://www.swig.org/Doc1.3/Python.html#Python_nn38 It surely would be welcome to get this resolved at the SWIG level. > Finally, are the SWIG interface files written manually? If time > permits, > I'll starting looking as these. Nope, the OCC code is introspected using pygcc_xml, the SWIG .i files are created starting from here. Cheers, -jelle _______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
