Hi,
In short, you are right - your C++ class name needs to begin with wx.
As wxPerl is a wrapper for the wxWidgets library, this isn't an issue -
that is the naming convention within the library and extensions.
If you are extending a wxWidgets base class in C++, then you need to
create a working C++ class first (which will be named wxSomething) then
you can wrap that using the standard helpers provided by wxPerl.
There are a couple of examples you could look at:
Wx::Scintilla
Wx::TreeListCtrl
These wrap fairly complex extensions so may not be that helpful for your
needs. Could you give more of a clue what you are trying to wrap or extend?
Regards
Mark
On 19/06/2011 23:07, Patcat88 wrote:
I'm trying to make a WX XS module. It seems to me, WxPerl can't tolerate
any wx derived class, that doesn't begin with "wx", I'm looking at the
code of wxPli_cpp_class_2_perl . The perl stash winds up being "wrong".
The module's package is "Foo" with Foo.xs and Foo.pm, the C++ class name
is Foo.
=========================
wxClassInfo *ci = object->GetClassInfo();
const wxChar* classname = ci->GetClassName();
=================================
returns a "Foo" string.
Doing a perl ref() on $fooobj returns "Wx::Foo".
All the perl methods from Foo dont work on $fooobj because $fooobj is a
blessed Wx::Foo not a Foo. Doing "Foo::aMethod($fooobj);" fails at
"if( !classname || sv_derived_from( scalar, CHAR_P classname ) ) " in
wxPli_sv_2_object, classname is Foo in the debugger.
wxPli_sv_2_object was called as
"Foo * THIS = (Foo *) wxPli_sv_2_object( aTHX_ ST(0), "Foo" );" inside
the post XS C code in "XS(XS_Foo_aMethod)".
So, I guess all WxPerl extensions must have a package name in Wx::
right? And why is this? What about naming conflicts inside Wx:: or a
class name collision between 2 classes with the same name in different
translation units?
