search for: reswigging

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

After reswigging I get link problems: Functions.obj : error LNK2001: unresolved external symbol _mWxruby2 Mac.obj : error LNK2001: unresolved external symbol _mWxruby2 Events.obj : error LNK2001: unresolved external symbol _mWxruby2 ... Which is intriguing since it seems to be defined in wx.cpp

This patch includes changes to implement the SashWindow sample. Some notes: 1) You can''t resize the sash windows due to events not returning the correct objects 2) I included a patch for EvtHandler.i even though it doesn''t affect anything at all. I only realized after I made the change but since it was wrong before I figured it''s better to have the right one in

Hi Think I tracked down why Windows suddenly went horrible crashy - the newest SWIG release generates slightly different code for object tracking, so our fixmodule.rb wasn''t picking up the broken line, so we got a nasty regression. Anyway, the patch (SVN:862) gives me a major improvement in stability Windows. Please could you let me know how SVN HEAD is working for you; if no major

Was trying to understand more about the internals of wxruby-swig, where does the big chunk of XML comes from? I saw something similiar in Python, is that massaged out of there? The codes produced by extractxml.rb and wxclasses-2.4.2.xml is quite different from the original header files. Just for example the WxDialog class. OnXXX are non-virtual in WxWidgets, but virtual in wxruby-swig

After decoding the unresolved symbols from wxruby2.so using c++filt, and comparing with the symbols provided by wxGTK, it became clear that wxGTK was using wchar_t whereas wxruby2.so was using char. So I rebuilt wxGTK, turning off unicode. That worked. No more unresolved symbols. What gives? Should the wxruby code have been built using wchar_t, and if so, how? However, now I get the

After re-swigging everything, manually correcting errors in the files mentioned before (and Functions.cpp) the library compiled and linked! This gets me over the hump of the reswig of wx.i I was getting before. Hopefully this will mean I can make some progress playing with things now. Although given Kevin''s recent e-mail about reworking the post-swig code... Roy

I would like to tag and release 0.0.37 soon. I''m thinking of the next few days. We have good new stuff (Printing, Scintilla on OS X, other new classes) and have fixed some bugs. Also, would be good to put the early build probs with the last release behind us. Here''s the patches I think are outstanding: - Wx::App cleanup - rake HTML docs publishing - Scintilla OS X -

Hi there, I am relative new to the wxRuby so please bear with me. I use Ubuntu Hardy Heron 8.04 release. I have installed the wxwidgets C libraries and then did a gem install wxruby The ruby extensions were downloaded and installed correctly. If i do $gem list --local .. wxruby (1.9.7) .. Then I tried to run a simple example "Hello World" as described in the tutorial

wxScintilla already comes with a SWIG friendly header file. I modified the rakewx and the Scintilla.i file to include it directly from the wxScintilla install. This means it''s an odd-ball compared to our other classes. Does anyone see a problem with this? I think it''s best to use the one supplied with the installation to avoid problems of the header file getting out of