similar to: SWIG -autorename

The result of the compilation after installing swig results in lots of errors of the sort: WindowDisabler.obj : error LNK2001: unresolved external symbol _SWIG_Ruby_ConvertPtr I can see this is defined in rubydef.swg but I''m not sure why this isn''t just included in the files that need it. Can any swig experts tell me what I need to do to progress? I''m using

SWIG 1.3.29 isn''t going to cut it for us. We''ll have to wait until 1.3.30, unless I can hack together a nasty workaround for a problem with the object tracking. It seem that each SWIG module gets its own hash for tracking objects. This means that, for example, you create a find dialog (in FindReplaceDialog.cpp) events you get from it (from FindDialogEvent.cpp)

I decided to try my hand at hacking SWIG and successfully produced a patch that fixes the error I demonstrated. I''m not -positive- it''s correct for all cases but I''ll re-run my version of SWIG over the library and see how things turn out. Roy

Attached is a patch for Swig that at least allows us to link the library. I am experiencing a number of bugs that will need to be tracked down and squashed. I haven''t even had time to look at the newer Swig features yet. Roy _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users

I was trying to fix the problem with wxImage and the char */unsigned char * thing today and I was going to hand-write the functions to translate between the two. While doing so I decided I''d clean up the SWIG error message to make it more clear. Here''s an example SWIG-generated argument error: in method SetData'', argument 2 of type ''wxImage *''

Swig is making mincemeat out of ComboBox.new. Because of the way it''s picking the ''correct'' one to call it''s calling with a null name instead of a default name. How did we fix this before?

You can''t rake without swig now. I keep swig out of my path so I can do a build without swig to be sure it works with the download. Exception `Errno::ENOENT'' at ./rake/rakewx.rb:20 - No such file or directory - swig -version No such file or directory - swig -version ./rake/rakewx.rb:20:in ``'' ./rake/rakewx.rb:20:in `have_good_swig'' ./rake/rakewx.rb:254:in

Swig''s bad interface generation strikes again. get_text_extent called with 1 argument maps to WindowDC''s _wrap_wxWindowDC_GetTextExtent__SWIG_0 Since this generates a wxFont that''s not initialized to nil it fails when calling into wxWindows. Anyone have a suggestion?

I have some conditional code based on the SWIG version. Current versions of SWIG 1.3.30 still don''t fix %trackobjects correctly so I''m going to remove the test for now so it builds correctly with my version of SWIG. Hopefully before 1.3.30 is released we''ll have a better trackobjects in SWIG. Roy _______________________________________________ wxruby-users

Anyone on the list have some pointers for getting swig working properly on Windows? Anytime I reswig a file it breaks wx.cpp. I''m sure I''ve got a setup problem but I haven''t been able to put my finger on it yet. Roy

About a year ago (ouch!), Robert Carlin submitted a ported version of the wxPython demo/sample. I hoped to include it in wxruby2, but it relies on SplitterWindow, which isn''t in wxruby2 yet. I tried to implement SplitterWindow myself, but got such strange results that I''m thinking I did something wrong. Even though the generated C++ code specified a variable number of

Take a look at the generated code from ListBox.cpp: static VALUE _wrap_new_wxListBox__SWIG_0(int argc, VALUE *argv, VALUE self) { VALUE arg1 ; wxWindow *arg2 = (wxWindow *) 0 ; wxWindowID arg3 ; wxPoint *arg4 = 0 ; wxSize *arg5 = 0 ; int arg6 ; wxString *arg7 ; long arg8 ; wxValidator *arg9 = 0 ; wxString *arg10 = 0 ; wxListBox *result; wxString

Two patches here: First one removes virtual from a function that shouldn''t have been virtual. Second one applies a typemap to catch GetRectFromChildWindow. For reasons that are completely beyond me the standard ruby OUTPUT typemaps don''t define directorargouts. I will take a stab at patching SWIG''s default typemaps someday so we get this fixed for free on all our

The latest cvs version of SWIG breaks a few things. I have patched common.i to fix most of it. There will be some other things later that should be compatible with all versions. Can someone test to see if this compiles with the old version? Roy -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: common.i.patch Url:

For whatever reason I decided to implement the validator class tonight. It''s my first go at implementing the class. My first run at it looked pretty good. I just added a generic .i for it and it all compiled. Sadly, the samples didn''t work because the base Validator class can''t actually be used as a validator! You have to derive from GenericValidator. I

I was investigating why the find dialog causes an error when you close it. It seems that wxRuby2 is returning a new ruby object when you call Event.get_dialog. This causes some big problems when you''re expecting you''re going to get back the same ruby pointer that you put in. In a brief check over the source I don''t see anything that preserves the original ruby

I''m trying to un-ignore TextCtrl#get_selection. The typemaps work fine, but in the process it breaks get_insertion_point. This is because (on Mac, tho not GTK), get_insertion_point calls get_selection internally and simply returns the first value. I think the return value is being converted from a long to a ruby int twice, because when get_selection is wrapped, it works fine but the

The following patches implement object tracking. Note nasty games I play to make the tracking global. SWIG 1.3.30 won''t need this. I also updated the minimum required SWIG version to 1.3.29. Roy _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users

The file swig/classes/includes/wxLayoutConstraints.h may need to be updated. It''s missing centreX and centreY from the list of wxIndividualLayoutConstraints. I''d send a patch in but I''m wondering if this file just needs to be regenerated from scratch. Roy

This patch fixes background color problems (at least on Windows). It uses the dreaded ''FIXME'' My plan for next weekend is to try building wxPython from the source to see how they manage to achieve several things with SWIG that we''re not (yet) able to. If I''m successful it might lead to wrapping a significant portion of wxWidgets more correctly than