Introduce-method refactoring should suggest a method name

[mbien]

if the test field is left empty, it creates the following problem:

• cancel button has focus, ok button is disabled until validation
• method name validation is delayed by 200ms which can cause users to cancel the hint after filling out the method name and pressing enter quickly, giving the wrong impression of a not functioning refactoring action

This can be avoided by initializing the test field with a method name.

bonus: Fixed an issue where a name conflict did not disable the introduce field dialog's ok-button

how to test:

• select System.out.println();
• alt+enter, select introduce method
• type something and hit enter quickly

[neilcsmith-net]

Seems an OK quick fix. Those should ideally be refactored to use validity support in dialogs? Problem seems caused by bypassing that and trying to achieve it manually? https://bits.netbeans.org/22/javadoc/org-openide-dialogs/org/openide/NotifyDescriptor.html#setValid-boolean-

Could also look at setting btnCancel.setDefaultCapable(false); ??

[mbien]

Could also look at setting btnCancel.setDefaultCapable(false); ??

this would be better than cancelling the dialog, however it could create the situation that pressing enter would do nothing the first time its pressed. If the user tries again 200ms later it would work - still not ideal

The trick here is to have the initial state of the dialog to be valid, like the other "introduce" dialogs. Those are able to suggest sensible input values, with the introduce-method refactoring this is more difficult.

This does also validate the default right away without delay, so it will disable the OK button if there is a conflict.

[neilcsmith-net]

however it could create the situation that pressing enter would do nothing the first time its pressed

If the OK button is disabled, then pressing ENTER should do nothing. No issue with prefilling with a valid value. But the user should still need to use ESC to cancel the dialog.

[mbien]

If the OK button is disabled, then pressing ENTER should do nothing.

the problem is that OK is disabled. You type something and it won't apply. The fact that cancel happens to be selected is just a followup issue, which is already fixed by having a default value and initial validation. I can set btnCancel.setDefaultCapable(false) but this won't really change anything on the original problem.

edit: the other "introduce" dialogs don't set that flag either, if we should change it we should change it for all comparable dialogs and not single out this one here.

[mbien]

rebase just to refresh since a lot happened in the meantime

[mbien]

@neilcsmith-net I looked through the hierarchy and added btnCancel.setDefaultCapable(false); to all fixes I found.

[sdedic]

On other places, ChangeSupport.run is run off EDT, since validators tend to use Parsing API which might be quite slow.

[mbien]

it is quite fast even in large files but I agree in principle. It is also run on focusLost() etc, so this would require more work.

[mbien]

so i debugged this and the whole panel initialization runs off-EDT(!), this call included ;)

What I did though to not make it worse: I removed this call to run() again, and triggered (async)validation when the default value is set.

[mbien]

well. this creates another problem i wanted to avoid. Now I probably going to have to init valid with true, otherwise it would appear to users which press enter quickly as if the keyboard isn't working.

[mbien]

I think I addressed all review comments, if there is more I should do or if I overlooked something please say so. Planning to merge this soon since I don't want to wait till last minute before freeze.

[mbien]

planning to merge this Thursday morning UTC a day before freeze.