Hi Christophe,
> (B) Well in fact I tried this afternoon the local OSG copy patching
idea, but it doesn't seem to work. I can't see why... taking the
LightPoint issue :
> {a} I've added two accessor methods in include/osgSim/LightPoint and
src/osgSim/LightPoint.cpp -> that 'updates' native osg dll and library
> {b} I've added those through I_Method and I_Method macros in
src/osgWrappers/LightPoint.cpp -> that should be taken into account by
Generator when generating again
Generator/output/src/osgSim/LightPoint.cpp and .h
> {a} worked perfecly but not {b} : the osgDotNet solution generation
still works but doesn't provide anything new into LightPoint class
definition...
> For instance I don't understand why.
Did you rebuild the osgWrappers/osgSim DLL? If that builds without
error the osgDotNet generator should see your additions. Note that the
build of the osgWrappers DLLs is not enabled in the default CMake
configuration; you need to turn on BUILD_OSG_WRAPPERS.
If you've got a Linux box handy, genwrapper is pretty trivial to get
started with. Just make sure you've got boost, doxygen, and libxml2
packages installed, and the follow the example at
http://www.openscenegraph.org/projects/osg/wiki/GenWrapper. On Windows
it's a pain because you need to set up all the dependencies yourself.
> > Currently there is a rudimentary mechanism in the code generator to
add custom support code to
> > classes. In the absence of support for operator functions in
osgIntrospection, this could be used
> > to handle the NodeCallback issue, including virtual calls from C++
to C#.
>
> I don't really understand what you mean by that ; can you tell me a
little more ?
Sorry... too many thoughts into too few sentences. :) Let me try to be
more explicit:
Take a look at the custom code items in the GeneratorConfiguration.cpp
file in the osgDotNet generator source. That mechanism is used to
insert arbitrary code into osgDotNet-generated wrapper classes, so
hand-coded wrapper functions to support NodeCallback::operator() could
be added there.
Currently genwrapper/osgIntrospection ignores operator functions, and
adding proper support for them is non-trivial, so this one-off
hand-coded approach is the best way to support them in osgDotNet right
now.
Virtual function invocation among wrappers, user-defined subclasses of
wrappers, and native code works in all directions by virtue of the
design of osgDotNet. This support also extends to hand-coded virtual
function wrappers if their implementations mimic the auto-generated
support code for virtual functions.
-Mike
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
