Bug 10136 - Selecting a symbol name should be the same as have the caret on it
Summary: Selecting a symbol name should be the same as have the caret on it
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P1 normal (vote)
Target Milestone: ---   Edit
Assignee: Dirk Baeumer CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-02-23 07:29 EST by David Corbin CLA
Modified: 2002-03-25 10:18 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Corbin CLA 2002-02-23 07:29:08 EST
As near as I can tell, unless the Outline view is open, all of the menu items on
the Refactor drop-down are disabled.  I don't use the Outline view.  I close it
get more editor real estate.  Refactoring should be divorced from this view.
Comment 1 Adam Kiezun CLA 2002-02-27 11:44:09 EST
fyi: some refactoring actions work also on multi-selection so you'll loose that 
functionality by using only the editor

the actions the global 'refactor' menu are enabled (if you have sth selection 
in the editor) - please provide more precise steps if you don't see them.
which build are you using?
do you see the global 'refactor' menu at all? (or were you referring to context 
menus?)



Comment 2 David Corbin CLA 2002-02-27 12:13:09 EST
I tend to use the global refactor menu, but I think I've misunderstood the problem.

The problem is that it is not sufficient to simply place the caret on the symbol
name, the symbol name must be actually selected to get the refactoring options
enabled.  I've notice this to be true with other things (Open in Editor, Open in
Heirarchy, Search) seem to have the same behavior.  I think the bug should be
re-written to reflect this behavior.  And will do so.

Sorry for not understanding.
Comment 3 Erich Gamma CLA 2002-03-11 09:31:46 EST
For accessability reasons having the care inside a symbol should be 
interpreted as the current szmbol. This should be supported by the JDT Core 
selection engine.

Once the JDT Core's selection engine provides this support we should adapt the 
OpenOn*, search, and refactoring actions. 
Comment 4 Philipe Mulet CLA 2002-03-11 10:45:52 EST
Jdt/Core support has been in since 20020212 (see bug 6064).
I remember there was an issue in the UI which explicitly disallowed empty 
selections to reach JdtCore. 

Are you saying you did remove the constraint in the UI and didn't see the 
selection work ?
Comment 5 Erich Gamma CLA 2002-03-11 13:15:32 EST
We have temporarily the empty selection constraint but didn't get any results 
back. We will release the code into the integration build of 20020312.
Comment 6 David Audel CLA 2002-03-12 06:29:31 EST
There is still a protection in Jdt/Core which doesn't allow to call 
SelectionEngine with empty selection.
This bugs is fixed. See http://dev.eclipse.org/bugs/show_bug.cgi?id=11152.

Comment 7 Erich Gamma CLA 2002-03-21 02:28:33 EST
Code resolve is now working properly on empty selections (resolving the 
identifier containing the caret). Open on Selection now works with empty 
selections.

The refactoring actions should be changed to allow emtpy selections.

Once refactoring is done we should do the same for the search actions.
Comment 8 Adam Kiezun CLA 2002-03-21 05:43:49 EST
the problem lies chiefly in StructuredSelectionProvider::asStructuredSelection
which returns an empty selection if 
FLAGS_DO_CODERESOLVE is set and textselection is of length 0
Comment 9 Dirk Baeumer CLA 2002-03-25 10:18:34 EST
Has been fixed by Daniel Megert. 

Fixed for build > 20020321