Hi, I started developing with wxRuby with the 0.1.0 release, and have been very pleased. As a ruby and wxWindows fan, I was happy to see the wxruby project, and have been very impresed with the implementation. I''ve been working on supporting the XML resources (wxXRC), and have an issue I''d like some advice on. XRC plugged in very nicely, and I was able to query resources. However, XRC depends on the wxWindow::FindWindowByFoo() methods. The problem is that since XRC creates the controls without wxruby''s knoweledge, they don''t exist in the cpp-to-ruby mapping table, and so wxruby wraps them as wxWindows (the default return type). My current solution to this problem has been to implement dynamic_cast(reference, Class) which will convert a wxWindows'' type to another one using the wxClassInfo. This works, and would be familiar to C++ and wxWindow''s programmers, but it strikes me as very un-ruby like. Also, it seems like a very high line item on an FAQ. (Q: I''m using XRC and my widgets all claim to be wxWindows! Whoever wrote wxXrcRuby sux0rs!) My two other solutions I can think of are 1) Add FindWindowByFooAsType(), where you can specify the return type of the object. This removes the need for the dynamic cast (or just moves the implementation), but it still seems a bit un-ruby like. 2) On loading of dialogs, iterate through all widgets, figure out what they are, and then add them to the cpp to ruby mapping table. This would solve the whole casting issue, but seems a bit like overkill (ok - I''m too lazy to consider it). I''m curious if anybody else has any suggestions/comments on this issue, which as we all know holds the free world in its evil clutches. Thanks, Nick *:-.,_,.-:*''``''*:-.,_,.-:*''``''*:-.,_,.-:*''``''*:-.,_:-.,_,.-:**:-.,_,. Register your domain names now at Wyith.net http://www.wyith.net
wxdevel@nicreations.net wrote: > I started developing with wxRuby with the 0.1.0 release, and have been > very pleased. As a ruby and wxWindows fan, I was happy to see the > wxruby project, and have been very impresed with the implementation. Thanks! > I''ve been working on supporting the XML resources (wxXRC), and have an > issue I''d like some advice on. XRC plugged in very nicely, and I was > able to query resources. However, XRC depends on the > wxWindow::FindWindowByFoo() methods. The problem is that since XRC > creates the controls without wxruby''s knoweledge, they don''t exist > in the cpp-to-ruby mapping table, and so wxruby wraps them as > wxWindows (the default return type). Assuming I understand what you''re saying, this is also a problem within wxruby itself. If you ask for the parent of a widget, for example, in some cases you will get back a generic type, instead of the specific type that the parent really is. I haven''t yet figured out a good solution for this, and I''m not sure if the best solution for the internal problem would also apply to classes defined in external libraries. I would love help from C++ folks and folks who are familiar with other GUI wrappers (ruby-FOX, wxPython, etc) to know how other projects have solved this. It certainly seems like a universal challenge. > 1) Add FindWindowByFooAsType(), where you can specify the return type > of the object. This removes the need for the dynamic cast (or just > moves the implementation), but it still seems a bit un-ruby like. That does not seem elegant, but does seem fairly simple. I wonder if you could pass the class type as a parameter, so you would only need one function instead of several. > 2) On loading of dialogs, iterate through all widgets, figure out what > they are, and then add them to the cpp to ruby mapping table. This > would solve the whole casting issue, but seems a bit like overkill > (ok - I''m too lazy to consider it). Perhaps this could be done more generally. First, we would need the ability to examine a single widget, and figure out the corresponding ruby class. Then we would need to be able to wrap that widget within that class. If we can do all that, then perhaps instead of pre-casting at dialog load time (which is an option) we might be able to just do the dynamic cast when someone asks for that widget in ruby. > I''m curious if anybody else has any suggestions/comments on this > issue, which as we all know holds the free world in its evil clutches. It does, indeed. Kevin