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 http://rubyforge.org/mailman/listinfo/wxruby-users
Roy Sutton wrote:> This patch file will allow the MDI example to run.Applied, thank you.> We''ll need to revisit it later.The mdi sample now doesn''t crash on OS X either, and displays a frame, but can''t create child windows.> There''s still a crash but it''s the same crash as from the scrolled > window example.What action provokes the crash? a
Alex Fenton wrote:> The mdi sample now doesn''t crash on OS X either, and displays a frame, > but can''t create child windows. > >> There''s still a crash but it''s the same crash as from the scrolled >> window example. >> > What action provokes the crash? > > >No action at all. It appears to crash pretty much right after it draws the scrolled window. I haven''t tracked it down but I''ll bet it''s a virtual/not virtual problem.
Roy Sutton wrote:> - virtual wxToolBar* GetToolBar() const; > + // TODO: Was virtual. Causes a crash if left virtual. > + wxToolBar* GetToolBar() const;I would still prefer: SHOULD_BE_VIRTUAL wxTollBar* GetToolBar const; or, at a minimum, using a FIXME commant instead of TODO. Not a showstopper for now...just a strong preference for the long run. Kevin
Kevin Smith wrote:> Roy Sutton wrote: > >> - virtual wxToolBar* GetToolBar() const; >> + // TODO: Was virtual. Causes a crash if left virtual. >> + wxToolBar* GetToolBar() const; >> > > I would still prefer: > SHOULD_BE_VIRTUAL wxTollBar* GetToolBar const; > > or, at a minimum, using a FIXME commant instead of TODO. > > Not a showstopper for now...just a strong preference for the long run. > >Oh, my bad. You did mention that before and I just blanked on it. Chasing these header file errors really drives me nuts. I think we need to look at what wxPython did. Here''s a relevant link that showed up on the SWIG mailing list recently:> A similar way that I use to rename classes and functions is to parse > everything with swig -xml and then run an xml parser on this to extract > the necessary symbols. You could use this to generate the proper #defines > into another file. > My script is basically a customized version of this one here (credits to > Robin Dunn from wxPython): > http://cvs.wxwidgets.org/viewcvs.cgi/*checkout*/wxWidgets/wxPython/config.py?rev=1.71.2.19&content-type=text/plain > . Just search for "processXML" (at the very bottom) in there to get the > function which extracts the proper xml data. > > -MatthiasRoy
Roy Sutton wrote:> Chasing these header file errors really drives me nuts.Me too! Especially across different platforms, where the inheritance chains are different.> I think we need > to look at what wxPython did. Here''s a relevant link that showed up on > the SWIG mailing list recently: >> A similar way that I use to rename classes and functions is to parse >> everything with swig -xml and then run an xml parser on this to extract >> the necessary symbols. You could use this to generate the proper #defines >> into another file.That is certainly an option. Even if we don''t use it to generate the actual headers, we might be able to use it as a reference point to compare with our headers for correctness. I mentioned doxygen as another option. This would be a great project for a non-core wxruby volunteer to take on (hint! hint!) Kevin