Community
Participate
Working Groups
Gpd (6/20/01 11:47:44 AM): Abstract : keyboard doesn't suit for editing attribute on Properties view Problem Description : Keyboard doesn't seem suited for editing attribute on the Properties view. Combination of Esc + cursor up/down are required every time when to move other attribute's value besides just above or under Misc. Information : Reported by : Y. Yamanashi Date : 06/13/2001 (mm/dd/yyyy) Frequency : S ("S"olid / "I"ntermittent problem) Environment : OS : Windows 2000 Eclipse build : wsa-jdk-20010612_1330-107-107 wsa-jdk-20010614_1300-107-119 Current implementation is ; 1. clicking the property or its value makes the value is selected and editable 2. esc key is required to cancel its editing mode 3. up or down arrow key allow cursor movement to up or down by one line and the value, where cursor has just located on, is now editable. So multiple Esc + arrow key operation is required to edit the property's value located far from the one where the cursor located first. On the other hand, on the ordinary spreadsheet application, like Lotus 123 or Microsoft Exel, or on the Explore of Windows, a user can move cursor only using up/arrow key to the place where a user wants to edit. Then a user presses some key, such as F2, to be able to edit that item. So at the point of the usability, keyboard should be more suited for editing attribute on the Properties view. NOTES: RG (6/20/01 3:40:06 PM) The "select activates cell editor" design has been present in the property sheet for as long as I can remember. This is also the way the property sheet worked in the VAJava VCE. I understand that it is nice to be able to navigate through the properties using up/down without triggering an editor but this is a design change that we should consider carefully.
PRODUCT VERSION: 119, Win2000
Tod, The property view need to be keyboard accesable. Pls verify that this is the case in the latest builds. If it isn't keyboard accessable make sure you talk to Randy before making changes,the implications are subtle.
Needs a way to swtich between navigation and editing like the tasks view will have.
To be addressed by the TableCursor work currently ongoing.
Removing dependency on 2817. The task list uses its own dialog now. We are not going with TableCursor.
You can switch back to navigation by hittign Escapre which means this is accessible (although not particulary usable). Removing The accessibility keyword and reassigning to Randy who is working on this.
Is now accessable, Defer work to make it more useable.
Reopen to investigate
The current implementation seems OK to me as far as navigation goes; it works this way: When no CE is active you can arrow up / down without activating the editor (which appears to be the original problem). Hitting 'Enter' (or a direct mouse click) activates the CE and then either Esc (to cancel) or Enter (to set) will generally get you back to the 'inactive' state. The one exception to this flow in our CE's is the DialogCellEditor which stays active once the value has been set so the flow is: Enter (activates) Enter (opens dialog) <fiddle with dialog> Enter (to accept) Esc (the ONLY way to dismiss the CE) [ soapbox on... ] I'd personally like to see the CE deactivate once the dialog has been closed (since the User has made their changes or cancelled). This would bring it into closer alignment with the other CE's. A fully consistent DialogCE would not have a button to open the dialog it; would simply open the dialog on activate and deactivate once the dialog has been closed, making its flow match the others exactly... [ soapbox off ]
Stale defect. There have been many changes in the UI since this defect was opened. If there will be additional work in this area a new defect report should be opened.
