#
b6c4fc96 |
|
01-Nov-2014 |
Rene Gollent <rene@gollent.com> |
Debugger: Implement #9946. TableCellValueRenderer{Utils}: - The rendering calls now take a boolean indicating if the value being rendered differs from its previous state. This is taken into account by rendering it in a different color to indicate the change. Adjust all implementing subclasses accordingly. VariablesView::ModelNode: - Now stores the previous value of the corresponding value node, and can be queried if its value has changed. Used by renderers. VariablesView::_{Add,Apply}ViewStateDescendentInfos(): - When walking the model, also store/restore the values of nodes in the history. In summation of all the above changes, when stepping through a function, we now display values that have changed since the last step, or that have appeared for the first time in a different color.
|
#
59ea286f |
|
05-Nov-2009 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b6c4fc962c6b0d6a0f071069fd0e90053e58f135 |
|
01-Nov-2014 |
Rene Gollent <rene@gollent.com> |
Debugger: Implement #9946. TableCellValueRenderer{Utils}: - The rendering calls now take a boolean indicating if the value being rendered differs from its previous state. This is taken into account by rendering it in a different color to indicate the change. Adjust all implementing subclasses accordingly. VariablesView::ModelNode: - Now stores the previous value of the corresponding value node, and can be queried if its value has changed. Used by renderers. VariablesView::_{Add,Apply}ViewStateDescendentInfos(): - When walking the model, also store/restore the values of nodes in the history. In summation of all the above changes, when stepping through a function, we now display values that have changed since the last step, or that have appeared for the first time in a different color.
|
#
59ea286fac914a808edc6989becc77dadff10383 |
|
05-Nov-2009 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
|