Community
Participate
Working Groups
I'm using an org.eclipse.ui.views.properties.PropertySheetPage. I can tab to it and navigate through the rows using the arrow keys. However, I cannot activate the cell editor using the keyboard. I'm forced to use the mouse.
Hi Mike! What version did you find this against? Which type of cell editor were you trying to activate? I just tried the org.eclipse.ui.examples.propertysheet example and the navigation seemed fine...for combos and text at least I could (when starting in an inactive state) arrow to the line, hit enter to activate and hit either enter or esc to get back...
I may have opened this bug prematurely. I was opening it on behave of someone else and didn't thoroughly test the scenario myself. Here's the complete story... The property sheet page is being used in both a multi paged editor and a wizard. From the editor I can activate the cell editor by pressing the enter key as you stated. The issue appears in the wizard. Pressing enter doesn't work because that causes the Next button to be activated. Instead of activating the cell editor the user is moved to the next wizard page. How can the cell editor be activated in a wizard that has a default button? Is there a way to change a wizard so it doesn't have a default button? I did a little bit of digging around for an answer and found out that once I have the shell I can call the method setDefaultButton. This doesn't work for wizards because, as the javadoc of this method describes, passing null doesn't always remove the default status from a button.
Does the development team have enough information to go on here? It sounds like embedding in a wizard is the only problematic scenario. I poked around in the Eclipse SDK code and could not find a place where this page is used in a wizard. If I am correct about this, could the submitter provide a testcase? It would be good to get an accessibility bug such as this fixed as soon as possible.
I thnk that Mike has covered the issue fairly well. Mike, can you point me at a Wizard that uses the property sheet?
Mike or David, can you answer the question in comment 4?
I spoke to Eric Moffatt offline about this and I think he has enough information to proceed. Essentially I said that I don't know of a public wizard that uses the property sheet page, but I could provide my internal one to him so long as it didn't show up in a public area like this bugzilla.
I've just finished an email thread with someone named Howard Lau regarding the same issue...here's what I sent him...(the context is he's asking how to override the 'Enter' key in PSP's) Sorry Howard,but the honest answer is 'no'. I agree that this is an issue with using property sheets in Wizards. The best I can see on short notice is that you might try: On page activation: Button originalButton = getShell().getDefaultButton(); getShell().setDefaultButton(null)'; On page deactivation: getShellI().setDefaultButton(defaultButton)'; While this will make the PSP work correctly it means that the user will have to physically click the 'Next/Finish' button when they want to move on. Even were it possible to detect the (de)activation of a CellEditor it wouldn't really help since we use the 'Enter' key both to start editing a cell and to end editing a cell. This is not really an accelerator, the activation is caused by the PropertySheetViewer trapping the 'default selection' event for the tree (which is generated by the platform on 'Enter'). Essentially this is a race between two different platform specific paradigms each trying to process the same key; One is the Dialog's handling of the 'Default button' and the other is the Tree widget's generation of a default selection event in the tree widget showing the properties. It looks like in this case the dialog's default handling is winning.
As I mentioned in comment #2 of this bugzilla, I don't think the suggested workaround will work. Here's a snippet of the javadoc for the setDefaultButton method: * If the argument is not null, sets the receiver's default * button to the argument, and if the argument is null, sets * the receiver's default button to the first button which * was set as the receiver's default button (called the * <em>saved default button</em>). If no default button had * previously been set, or the saved default button was * disposed, the receiver's default button will be set to * null. For wizards, passing null as the default button will simply reset the default button back to the original, not remove it. I guess if there aren't any other suggestions we'll just have to live with this limitation for now.
Sorry Mike, missed that...what happens if you disable the default button (as opposed to 'undefaulting it)?
Disabling the button did allow me to press enter on the PSP to activate the cell editor. The default button for wizards is the finish button. I think your suggestion will work for wizards that do not allow the user to finish early. However, for wizards that allow the user to hit finish at any point in time (which is what my wizard does) this won't be an option.
Created attachment 48575 [details] Proposed patch for 3.2.1 Kevin, +1?
The patch makes the 'Insert' key work like the 'Enter' key (for Text and Combo CE's), making them usable in Wizard/Dialog contexts.
Created attachment 48588 [details] Try over-riding the Traverse 'return' handling Just for Mike to test...it still includes the old code for Insert which will (hopefully) be unnecessary if this works.
OK, I think I've finally learned enough to answer the original question of how to 'disable' the Default button handling on a Wizard/Dialog. If you created a PropertySheetViewer named 'propViewer' then the following code should work to get the Property Sheet working in a Dialog/Wizard... // Prevent Wizard/Dialog 'default' buttons from executing prepViewer.getControl().addTraverseListener(new TraverseListener(){ public void keyTraversed(TraverseEvent e) { if (e.detail == SWT.TRAVERSE_RETURN && e.stateMask == SWT.NONE) { // Inhibit other handlers e.doit = false; } } }); Mike, could you please try this just to make sure that it'll work. I'll fix this in the PropertySheetViewer itself in 3.3 (in case other clients want to do it) but for 3.2.1 it'd be best to contain the change locally (i.e. in your code...;-). Let me know how it goes...
Adding the TraverseListener to my code worked. I can use this for now and remove it once my product moves to Eclipse 3.3. Thanks Eric.
With regard to commment 14 and comment 15, should the target milestone now be set to 3.3?
We should adopt this in a sensible manner (i.e. only when hosted in a Wizard??).
The target is 3.3 - will it make it?
Thanks for the heads up Mike...sorry but it's too late now...
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
