Opened 11 years ago
Closed 10 years ago
#9946 closed enhancement (fixed)
Debugger: Highlight most recently changed variables
Reported by: | stippi | Owned by: | anevilyak |
---|---|---|---|
Priority: | low | Milestone: | Unscheduled |
Component: | Applications/Debugger | Version: | R1/Development |
Keywords: | Cc: | bonefish | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
When stepping over code which changes the value(s) of (a) variable(s) visible in the Variables view, it would be cool to have it/those somehow highlighted.
Change History (4)
comment:1 by , 11 years ago
Cc: | added |
---|
comment:2 by , 11 years ago
I definitely don't want the Variable view to expand changed items, or highlight items when I expand them after stepping. Simply highlighting what's already visible if it changed during a Step operation, would be just perfect for me.
comment:3 by , 10 years ago
Status: | new → in-progress |
---|
Will see what I can do with this one next, though I'm not sure what my free time will look like in the near future.
comment:4 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
Implemented in hrev48206.
Note:
See TracTickets
for help on using tickets.
In and of itself, this shouldn't actually be all that difficult, there's essentially just one hurdle, and one question that needs clarifying. The latter is simply, would newly declared variables count as such a change or not? e.g. when stepping into a new lexical block such as an if, where a declared variable comes into scope for the first time.
The main hurdle is that, currently, Debugger lazily fetches variable values as the user actually asks to look at them, e.g. a class's member values aren't actually retrieved until you first click to expand it. As such, in order to implement this enhancement that behavior would have to be somewhat changed, so as to have the requisite values to compare between steps. This then begs the question of what depth to limit that behavior to though, since part of the reason for the current behavior is to prevent issues with e.g. doubly linked lists where one can potentially follow nested member links forever.