Hi, I added a missing feature in Wx::App that let''s you handle in one place exceptions raised in any event handler (without exiting the main_loop, so that these exceptions may be not fatal to the app). At that time I found that the docs of Wx::App and the code itself are not in sync. I''m in the process of creating a ticket with a patch for this. Before I complete the patch, I request some comments on these methods: #on_fatal_exception #on_unhandled_exception #on_exception_in_main_loop As these methods are designed to deal with C++ exceptions, shouldn''t we simply %ignore them in wxRuby? (That''s my proposal) Additionnaly, I found that App.i doesn''t %include "wxApp.h" at all, the class definition is inlined in App.i directly (at the end of file). So should we get rid of "wxApp.i" ? Regards, Pascal -- Posted via http://www.ruby-forum.com/.
Pascal Hurni wrote:> I added a missing feature in Wx::App that let''s you handle in one place > exceptions raised in any event handler (without exiting the main_loop, > so that these exceptions may be not fatal to the app). >That would be good. Ideally something that would work ruby-ishly - eg rescue. This discussion is probably better on wxruby-dev.> At that time I found that the docs of Wx::App and the code itself are > not in sync. I''m in the process of creating a ticket with a patch for > this. > > Before I complete the patch, I request some comments on these methods: > #on_fatal_exception > #on_unhandled_exception > #on_exception_in_main_loop > > As these methods are designed to deal with C++ exceptions, shouldn''t we > simply %ignore them in wxRuby? (That''s my proposal) >Yes.> Additionnaly, I found that App.i doesn''t %include "wxApp.h" at all, the > class definition is inlined in App.i directly (at the end of file). So > should we get rid of "wxApp.i" ?Probably not - the header files in swig/classes/include work as a list of the classes available, even if some of them aren''t used in building the wxruby library. thanks alex