Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Show debugging information on hover

<< < (6/6)

oBFusCATed:
Post your patch, more eyes see better :)
If you can clean your patch it will be great, if not so be it:)

cbexaminr:
current experimental development patch against svn 6604, wxpropgrid_debugger branch.

[edit: note, I had to modify eol properties to get svn to diff it... I don't know what implications are of that for applying this.]

obfusc, have a look when you can.  This may be closer to a starting point than I was before.  The approach is somewhat modified as to point in hierarchy where timer is managed from original demo (and my original point of major frustration.) On (MSW) wxwidgets, I have a timer that seems to be stopping of its own accord (which led me to the gdb/c::b file/path issues noted elsewhere), which I think I've currently hacked around, but would like to find as it may be either a wxwidgets or codeblocks issue of some sort.  Remember, there are borders currently, there's two lines in tipwindow.h that can be swapped, borders are a difference of (currently) a compilation flag.  Number of rows displayed is currently "default"ed to two (plus possible scroll items), but that is constructor value also (envision something like 10 maybe being a medium, maybe user should eventually be allowed some flexibility to choose within limits.) And code is cleaner than when I posted before, but still very much experimental with some retained "history".

Data display is not good, just whatever default comes in GDBValue, which seems a little strange particularly for array of char (don't seem to be any children for array of char.) At any rate, data value display/editing could benefit from a lot of add'l work.  Width of displayed items prob. will require changes too, some adjustment made relative to entity names, but not for data values.

Also can envision desireable possibility of "tack"ing items so that several might be brought up quickly and held, rather than just current single.  (I personally have never faired too well using the "watch" window functionality in debuggers.)

A "history" snapshot/logging function might be pleasant to have as well.  (Until some of this effort I wasn't aware of gdb's "history" value retention from print.)

And I can imagine a little more as well.  (Such as something along the lines of what I think gdb's "watchpoints" can accomplish, breaking briefly to report some state and then continuing - but that's not really part of tips.)

But, I guess the base needs to be there first...

Navigation

[0] Message Index

[*] Previous page