similar to: Object map

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

Wow. Look what SWIG does to GetTextExtent in Grid.cpp: void SwigDirector_wxGrid::GetTextExtent(wxString const &string, int *x, int *y, int *descent, int *externalLeading, wxFont const *font) const { ... if (swig_get_up()) { wxWindow::GetTextExtent(string,x,y,descent,externalLeading,font); return; } obj0 = rb_str_new2((const char *)(&string)->mb_str());

When implementing EVT_PAINT handlers in c++ the PaintDC object is constructed at the beginning of the function, and auto destructed at it''s end, which informs wxwidgets that "invalid regions in the window have been repainted". Under ruby, this is not the case and causes a stream of EVT_PAINT events to be sent to the given window (until one of PaintDC objects is destructed by

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 just re-integrated fixdeleting.rb, the last of the post-processors. Running minimal.rb no longer segfaults on exit. Running dialogs.rb and immediately exiting doesn''t segfault, but bringing up a dialog and then exiting does. So there are still memory problems, but fewer than yesterday :-/ I''m not sure how it compares to last week. I probably won''t have much time

I see that this problem was noted a while ago (http://rubyforge.org/ tracker/index.php?func=detail&aid=251&group_id=35&atid=218) but it seems not to have received much attention. Any chance that it will be looked at anytime soon? So far, I prefer wxRuby to Ruby/Tk because of that closer coupling with the native window manager. However, the memory leak is just murdering me.

Have tracked down a fairly serious cause of memory leakage in wxRuby2. swig/fixdeleting.rb adds a hash mapping from pointer address to ruby VALUE in every director initialiser using GcMapPtrToValue. The problem is that being a value in this global hash means that every Wx::Bitmap (for example, and others) are always marked in ruby''s GC mark phase, so they are never collected until

For debug builds we define __WXDEBUG__ and WXDEBUG=1. In the swig code we add a check for wxDEBUG to directors. My guess is we mean for one of those defines to be the other. Which one should we change? wxDEBUG-> WXDEBUG or WXDEBUG-> wxDebug? Roy

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

A few days ago, someone asked me why I am using wxpp instead of SWIG. The question prompted me to revisit and re-evaluate SWIG, and I now believe it would be best to convert wxRuby to SWIG. SWIG has greatly improved its C++ support since the last time I looked at it, and I think its Ruby support has improved quite a bit as well. Also, now that I have written wxpp, I understand the nature of

This patch implements a more generic solution to the problem that will work for all our integer types at least. Use this instead of the last version I sent, please. Roy _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users

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

Hi Just a quick update on memory leaks etc. I''ve just dropped a bunch of patches with a new approach to linking ruby''s GC to Wx''s memory handling. Still some work to do - eg bigdemo.rb falls over quite quickly - but working well for me on other samples. Briefly, it disposes of fixdeleting. For almost all objects that aren''t Windows, they should now be

Hi All, I have been learning some ruby and some Camping at the same time by implementing a little webapp to track expenses (one man''s blog...) that includes the ability to tag entries with 1 or more tags. I wanted to offer the possibility to narrow the view of expenses by adding tags to a filter (this works) and I also wanted this filter to be reflected in the URL. Like so: normal URL:

This patch file will allow the MDI example to run. We''ll need to revisit it later. There''s still a crash but it''s the same crash as from the scrolled window example. I''ll send a patch later that fixes the problem with DrawLines. Roy _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org

Hi Just started with WxRuby after using Fox. Very impressed by the easy binary install and I''m already liking the native look and feel on MSW. Thanks! I''m trying to create an app with a MDI Parent Frame and a full-height (docked) side panel with various controls in it. The MDIParentFrame doesn''t work properly if I put it inside another frame with a sizer, so

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

Hello again, I''m noticing that many of the headers in swig/classes/include have the comment: // This file was automatically generated // by extractxml.rb, part of the wxRuby project // Do not make changes directly to this file! Is this still the case, or was this just a one-time conversion? 228 out of 441 files in that directory don''t have the comment. I ask this because

I feel like I''ve mostly been banging my head against header file issues for the last couple weeks. I don''t feel like I''ve gotten any actual ''work'' done on fixing wrapping problems, adding new classes or improving the samples. I''m searching for any but haven''t found ''em. Some things I''ve noticed: 1) Some

Hi Attached, patches to implement ListItem. This class, in wxruby 0.6.0, allows styling of individual items in a ListCtrl, via a particularly clunky API. In disambiguating the overloaded ListCtrl#set_item method it introduces one non backwards-compatible change. I''ve followed the WxPython convention as described in the Wx class ref, renaming set_item(index, col, string, imageid) to