similar to: Handling int pointer parameters

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());

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

Hi The attached patches enable the use of SWIG''s *INPUT *OUTPUT and *INOUT typemaps as described in the manual. It''s done by including SWIG''s own ''typemaps.i'' file so it''ll allow us to benefit from future upgrades to that. The problem was a collision between a Ruby macro _ (fixing for old compilers) and a WxWidgets macro _ (for text

Hi Have been looking again at SWIG output pointer parameters, as: http://www.swig.org/Doc1.3/Ruby.html#Ruby_nn32 The problem is, whenever I tried to include the SWIG/Ruby ''typemaps.i'' file, it threw loads of errors. A bit more investigation pinned the problem down to some secondary files that typemaps.i includes to map ''special'' types like File. So I tried

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

The attached fixes set_item_data, get_item_data and some other methods for the TreeCtrl so they work nicely with Ruby objects and GC. In C++ Wx TreeCtrl item_data works differently from client_data in classes derived from ControlWithItems (eg Choice, ListCtrl). A one-to-one mapping of the way TreeCtrl works would mean that you would have to derive a class from TreeItemData, and instantiate

In the dialogs.rb sample, when you click the delete button you get: C:/RubyDev/wxruby2/samples/dialogs/dialogs.rb:61:in `onButton'': undefined method `free'' for #<Wxruby2::Button:0x36474b8> (NoMethodError) Should all/some wxObjects have a free function? how do we intend to handle this?

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

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 cut-n-pasted the public section from the wxWindows headers. Several things were missing so it seemed the easiest way to fix it. This fixed a problem with the way the overloaded new was being handled. This correctly generated all the versions so that it won''t have the problem with the non-initialized default parameters. I will admit I haven''t done serious testing on

This patch adds %directorout typemaps for the GetTextExtent functions _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users

The recent changes for windows in choice.i (not the unicode change) broke the etc/choice.rb and the controls/controls.rb tests. ../samples/etc/choice.rb:12:in `initialize'': No matching function for overloaded ''new_wxChoice'' (ArgumentError) Jani

These patches allow the RMagick sample to work with wxRuby2. They also open up some functions that were %ignored that probably shouldn''t be (at least with the typemap adjustment). I think we may need to visit (or document carefully) what happens when you pass in a string of data to the constructor or to SetAlpha. We need to decide which setting of static_data is correct for the

Attached are patches to make the textctrl.rb sample work fully. Note the new %directorargout typemap I added to fix wxWindows calling into SWIG. I don''t know if this can fix all such problems or not. Let me know what you think. I also rubified the sample a little bit more. Also, note that I fix the << operator so the function can be called. I hope I did this right. Roy

Here''s a patch to fix Wx::Window#get_text_extent - it requires that the patches from teh last message are applied, to enable *INPUT etc typemaps. Roy - though the function works correctly when called from Ruby, it still causes a crash when called internally when clicking on a Wx::Grid cell. Saw your message on SWIG mailing list, hopefully someone there can help out. alex

Hi. Attached you find an attempt to adding MediaCtrl to WxRuby. It''s only tested on windows (compiled with msvc 6.0). Everything seems to be working fine except for a small problem with a few functions: wxFileOffset Seek(wxFileOffset where, wxSeekMode mode = wxFromStart); wxFileOffset Tell(); //FIXME: This should be const wxFileOffset Length(); //FIXME: This should be const

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

Attached is a patch file for FileDialog.i. It doesn''t work 100% yet because I haven''t yet figured out how to make it put the ruby declarations in the right place. If I cut and paste the rb_define_methods into the right place this works perfectly. This patch fixes the dialogs.rb multiple select example so that get_paths and get_filenames returns a ruby array. Note that I

Here''s an example of the problem I was talking about the other day. Take a look at Button.i. It imports from its entire heirarchy. If you look at Button.cpp you will see that no wrappers are generated for anything except the button functions. This brings up some other things that we''ll need to keep in mind: If we''ve created a typemap in a .i file in classes and

StatusBar.i -- Adds a typemap to return a wxRect structure. You''ll really want to go over this to make sure it''s correct. I don''t have a sample but it did make part of one of the bigdemo samples work a little better. If you want to put this on the back-burner until we have a chance to test it more fully I''d understand completely. One of the things