Community
Participate
Working Groups
The no-columns mode in variables, registers, and expressions views is now better supported thanks to changes from bug 225650. However, now when the view is in no-columns mode, it is impossible for the user to edit a variable value. Two options: 1) Enable the "Change value" action for DSF-based values. 2) Enable in-line editing. ... or both.
Created attachment 154783 [details] Patch Here's the patch that will enable 'Change Value' action in Register, Variable, and Expressions views. The following is a summary of the changes made: New Files: - IModifiableDMContext: A DM Context that wants to support 'Change Value' action should implement this interface - DsfValue: This class implements org.eclipse.debug.core.model.IValue, which was needed to support 'Change Value' action Modified Files: - IExpressions: Introduced IExpressionDMContext2 which implements IModifiableDMContext. Any ExpressionDMContext that wants to support 'Change Value' should implement IExpressionDMContext2 - IRegisters: Introduced IRegisterDMContext2 which implements which implements IModifiableDMContext. - IStack: Introduced IVariableDMContext2 which implements IModifiableDMContext. - RegisterVMNode: RegisterVMC now implements IValueModification and IVariable - RegisterBitFieldVMNode: BitFieldVMC now implements IValueModification and IVariable - VariableVMNode: VariableExpressionVMC now implements IValueModification and IVariable
Please note that in order to test out this patch, you have to modify your Register/Variable/Expression DMContext to implement IRegisterDMContext2, IVariableDMContext2, and IExpressionDMContext2, respectively.
Thank you for the patch, though perhaps we should first try a different approach. We are not able to fully implement the standard model's IVariable and other interfaces so if we start going down this path we eventually get ourselves into some trouble down the road (unexpected NPE's etc.). Also, we already have an API for determining if a value can be modified (IExpressions.canWriteExpression()) and it is asynchronous on purpose to allow debugger implementation to query a remote debug engine. Instead, I think we should completely duplicate the Change Value... action and it's corresponding dialog. The action enablement will need to be asynchronous, which of course will be more complicated but it's been done before. On the platform side, I'll file a bug to hide the standard model's "Change Value" action when the selected element is not an IValue.
(In reply to comment #3) > Thank you for the patch, though perhaps we should first try a different > approach. We are not able to fully implement the standard model's IVariable > and other interfaces so if we start going down this path we eventually get > ourselves into some trouble down the road (unexpected NPE's etc.). Also, we > already have an API for determining if a value can be modified > (IExpressions.canWriteExpression()) and it is asynchronous on purpose to allow > debugger implementation to query a remote debug engine. > > Instead, I think we should completely duplicate the Change Value... action and > it's corresponding dialog. The action enablement will need to be asynchronous, > which of course will be more complicated but it's been done before. On the > platform side, I'll file a bug to hide the standard model's "Change Value" > action when the selected element is not an IValue. The description of this bug doesn't indicate any plan for hiding the action. The first option is to: "1) Enable the "Change value" action for DSF-based values.". I wish I'd knew there was a plan to hide the platform action before I started working on this :) Can you please CC me on the defect you plan to open on the platform side? Thanks!
(In reply to comment #4) > (In reply to comment #3) > The description of this bug doesn't indicate any plan for hiding the action. > The first option is to: "1) Enable the "Change value" action for DSF-based > values.". I wish I'd knew there was a plan to hide the platform action before > I started working on this :) I'm sorry if the initial bug description was misleading. > Can you please CC me on the defect you plan to open on the platform side? > Thanks! Will do.
Looking at the platform implementation a bit, it seems that we'll need to allow for different editor types for different values. We could do this most easily by re-using the IElementEditor that the VM nodes implement already. The edit dialog would simply be a container for the cell editor and it would write the value using the cell modifier.
Created attachment 162194 [details] fix for bug in SyncVariableDataAccess In EDC, I have added a new editable variables detail pane as a partial solution for editing variables' values when in no column mode. I did not think the NumberFormatDetailPane in DSF was amenable to being editable given its multiple formats. The EDC variables detail pane has a context menu which can be used to set its current format without affecting the view's format. I had used internal EDC calls to implement it but realized I could just as easily implement it in terms of SyncVariableDataAccess. I have an implementation that could potentially be moved into DSF at some point. However, there is a minor bug in SyncVariableDataAccess that prevents me from even committing it into EDC. I am attaching a patch to address this small bug.
