Swig help extending wxFrame class

I'm working on porting a wxWidgets based game api I'm developing to
wxPython. I'm coming up to speed on swig and reading lots of wxPython
swig code, but am stuck on something and can't figure out how wxPython
'swigs' it. Perhaps someone can help.

Basically, I'm extending wxFrame with some new functions, and changing
the implementation of some, such as SetTransparent. However, when I
try to call the SetTransparent from my class, I get

Traceback (most recent call last):
  File "C:\Program Files (x86)\Wing IDE 3.2\src\debug\tserver
\_sandbox.py", line 1, in <module>
    # Used internally for debug sandbox under external interpreter
  File "c:\Users\rod\KlickFu\Devel\wxPython-src-2.8.10.1\wxPython\wx
\klickfu.py", line 99, in SetTransparent
    return _klickfu.KfFrame_SetTransparent(*args, **kwargs)
TypeError: in method 'KfFrame_SetTransparent', expected argument 2 of
type 'wxByte'

The relevant snip from my swig file looks like

class KfFrame : public wxFrame
{
public:
    %pythonAppend KfFrame "self._setOORInfo(self)"
    %pythonAppend KfFrame() ""
    %typemap(out) KfFrame*; // turn off this typemap

  KfFrame(wxWindowID id,
            const wxPoint& pos = wxPoint(0,0),
            const wxSize& size = wxSize(0,0));
    %typemap(out) KfFrame* { $result = wxPyMake_wxObject($1,
$owner); }

  virtual ~KfFrame();

  virtual bool SetTransparent(wxByte alpha);
//...

SWIG doesn't know that wxByte is an integer-like type and so it is assuming that it is a class and will try to do strong type-checking of the object that is passed to it. You can fix this by letting SWIG see a typedef for wxByte, or just #define it to be some fundamental type. I have a few of these already in _defs.i.

···

On 9/17/09 2:48 PM, RM wrote:

I'm working on porting a wxWidgets based game api I'm developing to
wxPython. I'm coming up to speed on swig and reading lots of wxPython
swig code, but am stuck on something and can't figure out how wxPython
'swigs' it. Perhaps someone can help.

Basically, I'm extending wxFrame with some new functions, and changing
the implementation of some, such as SetTransparent. However, when I
try to call the SetTransparent from my class, I get

Traceback (most recent call last):
   File "C:\Program Files (x86)\Wing IDE 3.2\src\debug\tserver
\_sandbox.py", line 1, in<module>
     # Used internally for debug sandbox under external interpreter
   File "c:\Users\rod\KlickFu\Devel\wxPython-src-2.8.10.1\wxPython\wx
\klickfu.py", line 99, in SetTransparent
     return _klickfu.KfFrame_SetTransparent(*args, **kwargs)
TypeError: in method 'KfFrame_SetTransparent', expected argument 2 of
type 'wxByte'

The relevant snip from my swig file looks like

class KfFrame : public wxFrame
{
public:
     %pythonAppend KfFrame "self._setOORInfo(self)"
     %pythonAppend KfFrame() ""
     %typemap(out) KfFrame*; // turn off this typemap

  KfFrame(wxWindowID id,
             const wxPoint& pos = wxPoint(0,0),
             const wxSize& size = wxSize(0,0));
     %typemap(out) KfFrame* { $result = wxPyMake_wxObject($1,
$owner); }

  virtual ~KfFrame();

  virtual bool SetTransparent(wxByte alpha);
//...

--
Robin Dunn
Software Craftsman

That did the trick, obvious now that I get it.

Another question: why do you turn off the pointer typemap for various
constructors, e.g., wxWindow? Does it have to do with wxEvtHandler
derived objects already having a Python object (mentioned in
wxPyMake_wxObject)? I'm trying to decide if I need to follow that
practice for my derivation.

I.e.,

    %typemap(out) wxWindow*; // turn off this typemap

    DocCtorStr(
        wxWindow(wxWindow* parent, const wxWindowID id=-1,
                 const wxPoint& pos = wxDefaultPosition,
                 const wxSize& size = wxDefaultSize,
                 long style = 0,
                 const wxString& name = wxPyPanelNameStr),
        "Construct and show a generic Window.", "");

    DocCtorStrName(
        wxWindow(),
        "Precreate a Window for 2-phase creation.", "",
        PreWindow);

    // Turn it back on again
    %typemap(out) wxWindow* { $result = wxPyMake_wxObject($1,
$owner); }

Sort of. I have a bunch of (out) typemaps in my_typemaps.i for many of the classes and those will take precedence in the wrapper code for the constructors. So by turning it off temporarily it allows the default SWIG wrapper code to be generated in the constructor instead of the typemap code. Turning it back on afterwards will then use the typemap anytime the class is returned from a function. I don't really need it for every class, but I tend to do it anyway to make sure that I don't forget to do it when it is necessary.

···

On 9/18/09 6:10 PM, RM wrote:

That did the trick, obvious now that I get it.

Another question: why do you turn off the pointer typemap for various
constructors, e.g., wxWindow? Does it have to do with wxEvtHandler
derived objects already having a Python object (mentioned in
wxPyMake_wxObject)?

--
Robin Dunn
Software Craftsman