enhancements to wxStackFrame for Linux

[Francesco Montorsi]

Vadim Zeitlin ha scritto:
> 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.
very useful! it would make debugging easier, if only it were a bit faster ;)


> 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
right.

Commenting your last comment (sorry for the word play) to that bug report:

 >the best thing I see is to keep a global
 >(well, static in wxStackFrame) list of all stack frames and
 >when OnGetLocation() for any of them is called also retrieve
 >the location of all the other ones.

since calling addr2line only once means that in any case we must keep in 
memory the result of all the parsing, why not just add a 
wxStackWalker::InitFrames which is called by wxStackWalker::Walk and 
which simply intializes an array of wxStackFrames that are then passed 
one by one to OnStackFrame() ?

I don't see why wxStackFrame should hold a list of the (other) stack 
frames, when the "manager" class is wxStackWalker... in any case this is 
an implementation detail which is hidden to the user so I don't think 
it's a crucial thing.


> 
> 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.
ah, right. I didn't consider that.


>  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.
ok, but under wxGTK I'd say to use this new generic version as default 
since currently reading all the stack frame wrapped by the dialog is a 
pain (I don't remember right now - do the stack trace gets wrapped on 
wxMSW's msgbox ?).

Also, I propose to strip the arguments from the function names 
(fnc(typeA a, typeB b, typeC c) => fnc); e.g. wxOnAssert takes a lot of 
arguments making the line for that call very long. And they are not very 
useful to the developer...

They are useful to differentiate between two overloads but in that case 
also the line number will help...

Francesco