[wx-dev] enhancements to wxStackFrame for Linux

Vadim Zeitlin vadim at wxwindows.org
Wed Nov 1 06:13:05 PST 2006


On Wed, 01 Nov 2006 12:54:07 +0100 Francesco Montorsi <f18m_cpp217828 at yahoo.it> wrote:

FM> I'm walking through my TODO list and I'm now trying to enhance 
FM> wxStackFrame under Linux.

 This would be great, useful as it is, there are definitely a few serious
problems with it.

FM> It currently takes up to 40 seconds on my Athlon 3Ghz to show up the 
FM> debug message box. So there's really room for improvements :D

 See 

http://sf.net/tracker/index.php?func=detail&aid=1534704&group_id=9863&atid=109863

FM> That greatly improved readability of the message box, so maybe we 
FM> should really consider to make wxGenericMessageDialog always available.

 The motivation behind using wxMessageDialog was to avoid using wx classes
and call the native OS function directly to decrease the probability of
crashing/asserting again. This can be difference between getting useful
information and crashing with "assert inside assert" on the systems which
do have a native wxMessageDialog such as, you guessed it, Windows.

 So while I do agree with Vaclav's suggestion to use wxCollapsiblePane in
the generic version (BTW, this reminds me that it would probably make sense
to use it in wxLog dialog too), I'd like to continue using wxMessageBox
under Windows.

FM>   4) all the time is mostly lost by calling multiple times addr2line 
FM> which has to load in memory all the times the ELF (which with debug info 
FM> is in my case about 47 MB !!!). This is unacceptable since addr2line 
FM> accepts multiple addresses.

 Yes, this is what the bug above is about.

FM> However I don't really understand why it wasn't implemented in this way 
FM> from the beginning... am I missing something?

 I didn't realize it would be such a serious problem, so I just went for
the simplest possible implementation. Clearly, it wasn't enough.

 Regards,
VZ





More information about the wx-dev mailing list