Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 250713 - "Override/Implement Methods" insertion point doesn't respect cursor position
Summary: "Override/Implement Methods" insertion point doesn't respect cursor position
Status: RESOLVED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.4.1   Edit
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-14 00:59 EDT by Matt Whitlock CLA
Modified: 2008-11-13 08:36 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Whitlock CLA 2008-10-14 00:59:27 EDT
Build ID: M20080911-1700

Steps To Reproduce:
1. Be editing a Java source file.
2. Position the insertion point (text cursor) between two methods.
3. Invoke the "Source > Override/Implement Methods" tool.
4. The "Insertion point" for the new method(s) defaults to "First member" rather than the "After fooBarBaz()" corresponding to the method immediately after which the text cursor was positioned.

More information:
This is a regression bug.  The behavior was as expected in Eclipse 3.4.0 but is broken in Eclipse 3.4.1.
Comment 1 Dani Megert CLA 2008-10-14 02:54:09 EDT
There was a bug that first/last wasn't remembered. Simply select one of the methods and from then on it will default to the closest member.
Comment 2 Matt Whitlock CLA 2008-10-14 03:06:39 EDT
Oh, thanks.  I thought I'd tried that without success, but indeed it does seem to work now.  Sorry for the noise. :/
Comment 3 Stefan Baramov CLA 2008-10-28 15:16:10 EDT
I humbly disagree with the resolution of this bug. Essentially, the Cursor Position option disappeared from the option menu. The problem applies to all source editing wizards including "Generate Getters and Setters", "Generate Constructor using Fields..." and all others. 

The workaround suggest to pick the method name. However, this slows down the development process. Essentially, the developer is forced to search through the lists of methods until it find the correct one. This is fine for one or two methods. What about a class with 20 methods. In any case reduces productivity and it should be marked as serious bug. To me the work around is unacceptable. 
Comment 4 Dani Megert CLA 2008-10-29 04:17:56 EDT
>The workaround suggest to pick the method name. However, this slows down the
>development process. Essentially, the developer is forced to search through the
>lists of methods until it find the correct one.
You do not have to pick the method name each time. Only the first time and only when changing from a build < 3.4.1 to a new one. From then on it will preselect the method closes to the caret position. So, in case the default isn't already correct you have to do a one time member selection and you are back to the same behavior as with the old option.
Comment 5 Stefan Baramov CLA 2008-10-29 09:26:57 EDT
(In reply to comment #4)
> You do not have to pick the method name each time. Only the first time and only
> when changing from a build < 3.4.1 to a new one. From then on it will preselect
> the method closes to the caret position. 

It worked just fine. However I would argue that the above described behavior should have been the default choice. In other words, the wizard should have automatically picked up "After method xyz" instead of offering "First Method" choice by default. At least it would have been easier for people like me that have used Eclipse for years and are used to particular use case. 

Comment 6 Dani Megert CLA 2008-10-31 07:53:56 EDT
Stefan, this only happens if you either changed the setting once manually or if you invoked the wizard via Outline.

I think a better solution is to forget the old value  and restore the defaults one time. I've done that now for HEAD and 3.4.2.
Comment 7 Dani Megert CLA 2008-11-13 08:36:38 EST
*** Bug 255169 has been marked as a duplicate of this bug. ***