This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 55811 - [41cat] Overrides in the Add Method... Dialog
Summary: [41cat] Overrides in the Add Method... Dialog
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: PC Windows ME/2000
: P3 blocker (vote)
Assignee: Jan Pokorsky
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-03 04:07 UTC by jerosser
Modified: 2007-09-26 09:14 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Test Case, Results, and Analysis (2.41 KB, text/plain)
2005-03-04 02:32 UTC, jerosser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jerosser 2005-03-03 04:07:44 UTC
[ JDK VERSION : 1.5.0_01 ]

The Add Method dialog will not accept any method
name that either overrides an existing method in
the class or a method in the parent class.  An
Error dialog is presented indicating that this is
an override.  That dialog should be a warning with
two choices: Accept the method override, or Cancel
to try again (the current path).
Comment 1 Martin Matula 2005-03-03 13:38:01 UTC
Sorry, but I can't reproduce this. The Add method dialog works
correctly in my case - it refuses to add a method that already exists
in the source code, but allows to add a method that overrides some
other method from a supertype (if it does not already exist in the
current class).
I don't think that allowing to add a duplicate method into the same
class makes any sense. Please provide more info on what exactly did
not work in your case (steps to reproduce your problem).
Thanks in advance.
Comment 2 jerosser 2005-03-04 02:32:57 UTC
Created attachment 20666 [details]
Test Case, Results, and Analysis
Comment 3 Martin Matula 2005-03-04 10:00:54 UTC
Thanks for the test case. Unfortunatelly I am still not able to
reproduce it. Following your test case step by step everything worked
as expected - no error messages, all methods were generated correctly.
Moreover when looking at the code I can see that the complex name
validation (such as looking for whether a given name is already used)
is done only when user presses OK button. You are saying that the
error comes up when the "name" entry field loses focus. That is
strange because upon losing focus the dialog only checks whether a
given identifier is valid. Are you sure you are using NetBeans 4.1 build?
Comment 4 jerosser 2005-03-04 13:27:09 UTC
Very odd.  Definite that I'm running against 4.1 Beta.  Build number
200502222100.  VM shown as 1.5.0_01-b08.  W2K SP4.  I plan to pick up
the next daily build tomorrow so I'll try this again.  Based on your
description this definitly shouldn't be happening.  I'll let you know. 
Comment 5 Martin Matula 2005-03-04 13:41:19 UTC
Try to think about what you did before trying to add the methods. Did
you have a class with the same name in the project before and deleted
it? Or did you invoke some bean patterns related operations (add
property, etc.), or beaninfo editor?
Try the same thing with a completely new class with a completely new
name. Also is the class you are creating in the default package or
not? (it wasn't clear from your description)
Comment 6 jerosser 2005-03-04 14:26:17 UTC
Interesting questions.  From the top.
In most of the trials I made the class name was unique.  Generally
added a number at the end of the class name in the frag I attached.  I
did make at least one trial with the same class name after deleting
the older trial.  As noted the results from the trials are
inconsistant.  One thing that does occur to me is that the first time
through the case after starting NB was generally better than later
trials.  I'll have to check that again.

As far as I know I did not invoke a beam pattern operation, however,
this project is a javabean and does have a beaninfo class. Don't know
if that makes a difference or not.  This particular fragment is a
distillation from one of the property editors.

The class is part of a named package, not the default.  Sorry should
have shown that in the fragment.
Comment 7 Martin Matula 2005-03-04 14:50:07 UTC
Hm. Weird. If you find a 100% reproducible scenario when starting with
a clean userdir please let us know. Reassigning to Honza for further
evaluation.
Comment 8 jerosser 2005-03-31 16:48:35 UTC
Revisited test case on 0329 Q Build.

Dialog problems not repeated.

Suggest close - Overcome By Events(OBE) 
Comment 9 Jan Pokorsky 2005-03-31 17:12:44 UTC
I agree we can close this. Several problems of the method customizer has been
fixed in issue #49398 and issue #55947. So hopefully these fixes cover also your
case.