>
> 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.
I found a way round this by converting it to a TCollection_AsciiString
(which will accept an ExtendedString in it's constructor)
>
> As you know OCAF is a fairly new addition to pythonOCC, so thanks for
> pointing out these rough edges Bryan.
I think there's a lot to be done for OCAF. If I can understand the
wrapper creation process, I'll hopefully be able to contribute to the
wrappers myself.
I've hit a new blocker: I can extract attributes as TDF_Attribute
instances. Even when I can identify the underlying attribute class via
it's GUID, I don't know how to "downcast" the attribute to it's concrete
type, so I can access it's type-specific methods.
>
> Wow... pure torture... still impressive that you managed to do so, did
> you use ctypes?
Sorry to disappoint you. I didn't *actually* do this, but was "wondering
out loud" if an approach like this would work. I googled a bit on SWIG
and ctypes, since it seems like there ought to be a way to construct
pointers which SWIG will accept, using ctypes objects, but I couldn't
find anything.
Hacking round swig pointers isn't a practical approach except as a
tempory workaround to experiment with OCAF functionality. The right
approach is to "fix" the wrappers.
For Standard_GUID, there is another method: can convert them to a tuple
suitable for hashing with -
def GID2Tuple(gid):
return (gid._CSFDB_GetStandard_GUIDmy32b(),
gid._CSFDB_GetStandard_GUIDmy16b1(),
gid._CSFDB_GetStandard_GUIDmy16b2(),
gid._CSFDB_GetStandard_GUIDmy16b3(),
gid._CSFDB_GetStandard_GUIDmy8b1(),
gid._CSFDB_GetStandard_GUIDmy8b2(),
gid._CSFDB_GetStandard_GUIDmy8b3(),
gid._CSFDB_GetStandard_GUIDmy8b4(),
gid._CSFDB_GetStandard_GUIDmy8b5(),
gid._CSFDB_GetStandard_GUIDmy8b6())
Ugly, but it seems to work.
>
> > 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.
I have a some experience with SWIG, but I've never used pygcc_xml. It
would be useful if Thomas could briefly describe the approach he's
taking in making the wrappers. In particular, assuming pygcc_xml can
construct .i files covering the common cases, how do you handle special
cases? Do you just added a few manually created .i files?
cheers,
Bryan C
_______________________________________________
Pythonocc-users mailing list
[email protected]
https://mail.gna.org/listinfo/pythonocc-users
