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 28466

Summary: No feedback, nothing happens when entering duplicate file name
Product: platform Reporter: Ana.von Klopp <avk>
Component: Dialogs&WizardsAssignee: David Konecny <dkonecny>
Severity: blocker CC: benway, bmay, davidjon, jrechtacek, jrojcek, jtulach, mkleint, pkeegan, thp, ttran
Priority: P2 Keywords: UI
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 23116    
Bug Blocks:    
Attachments: possible patch
example of error message
example of a HTML formatted message in the wizard.
sample code of the inlined error notification.
Eliminates the dynamic nature of David's patch
screenshot of patch in action
source code patch
binary patch

Description Ana.von Klopp 2002-11-04 20:06:06 UTC
To reproduce: 

1. Create a web module with a JSP at the document root 
(say hello.jsp).

2. Switch to the project view of the module. 

Select the document base. 

4. Select New -> JSP. 

5. Enter the same 
name for the JSP as the one that already exists ("hello". 

6. Nothing 
happens. No dialog warning that the name is already used, the finish 
button is not enabled.
Comment 1 Petr Jiricka 2002-11-05 09:02:58 UTC
Well, if you are saying that certain behavior is wrong, 
you should also say what you think the correct behavior 
should be.

Also, have you tried this for .txt file ? The behavior is 
the same there, so the behavior for JSPs is consistent 
with other templates.

Please specify the desired behavior and file a bug against 

Comment 2 Ana.von Klopp 2002-11-05 18:56:52 UTC
Don't be such a curmudgeon! OK, here is what should happen: if a user hits 
enter in the text field, there should be an error message to the effect that 
there already is a file of that name. Also, instead of graying out the 
finish button (which means that the user has no idea what's going on), it's 
better to leave it enabled and show the warning then. 

To those of you on 
the openide team, this might seem like a weird thing for a user to do, and 
that is true in the Java space - it's fairly unlikely that users will want 
several Java classes of the same name in different subpackages. But in the 
web apps area, it's fairly common to have files of the same name in 
different directories. For example, I might have an index.jsp in several 
subdirectories of the web module. If I track badly, I select the wrong node 
before I start the new wizard, and this is where this confusing situation 

Comment 3 _ rkubacki 2002-11-06 08:06:23 UTC
If I understand well there is a proposal how to handle these cases in
the same way through the IDE. Should we join the discussion about it?
Comment 4 Petr Jiricka 2002-11-06 10:26:11 UTC
Ok, Ana, sorry for being mean. That won't happen again :-)

This is a reasonable request, but I still think it should 
be handled consistently through the IDE.

Unfortunately, what you are requesting is not possible in 
the current wizards framework. However, there is a 
proposal for enhancements which would address this. See 
issue 23116.
Comment 5 Ana.von Klopp 2002-11-06 20:11:43 UTC

I reassigned the bug to openide/ui (now to wizards, my browser 
didn't give me that category last time) because the file dupe is a generic 
problem and not a web apps one. Should I reassign it back to webapps? I note 
that 23116 provides the ability to give a warning/not go ahead after a 
button has been pressed, but doesn't include specific behaviour for 
duplicate file. Is the duplicate file behaviour part of the webapps code, 
or is it part of the wizard code in general?


Comment 6 Petr Jiricka 2002-11-07 10:08:33 UTC
> I note that 23116 provides the ability to give a 
> warning/not go ahead after a button has been pressed, 
> but doesn't include specific behaviour for duplicate 
> file.

This behavior is not intended to be a part of the "wizard 
framework" as such, but of the "new from template wizard", 
which is a particular wizard building on top of the common 
framework. So the framework will provide the ability to 
validate on pressing Next/Finish, and the New form 
template wizard will plug in the validation of duplicate 
name (when the Next/Finish button is pressed).

So yes, I believe this should be a part of the generic 
functionality, similarly to the current enabling/disabling 
the Finish button when duplicate name is entered.

Comment 7 David-john Burrowes 2003-01-09 19:05:44 UTC
I am increasing the priority on this issue because it is going to
significantly affect some of S1S EE (Rainier).  The "inline_errors"
solution mentioned in the url associated with this issue would be the
preferable fix and must be done eventually, but even a "hack" of
showing an alert explaining that the file name is not unique would be
good enough in the short term.

Comment 8 Jiri Rechtacek 2003-02-12 15:33:04 UTC
The issue could be tracked as enhancement, it asks a new functionality
by Jan's "inline_errors" proposal. It depends on issue 23166, will be
resolved in 4.0 timeframe.
Comment 9 David-john Burrowes 2003-02-12 20:45:49 UTC
I'm changing this back to a defect.  If the inline errors solution
isn't available, then an alert box is an acceptable alternative (as
suggested in the last message).  This really is needed for S1S for
Comment 10 David Konecny 2003-02-13 09:36:45 UTC
I'm going to help Jirka with this issue.
Comment 11 David Konecny 2003-02-13 16:59:29 UTC
It is clearly too late for implementation of inline_errors proposal
for NB3.5. The change would have impact on modules, their UI,
documentation, etc. so it is not realistic. AFAIK we are already in UI
freeze for 3.5.

So I propose to try to implement a hack which:
* left finish/next button enabled
* would show error message box in case there is an error and user
pressed finish/next button

I already have working patch, but I would like to discuss it on
openide@dev whether there is any better way or whether it is
apropriate. It is quite ugly solution.
Comment 12 David Konecny 2003-02-13 17:04:26 UTC
Created attachment 8938 [details]
possible patch
Comment 13 David Konecny 2003-02-13 19:34:10 UTC
Hmm, I just realized that it might be easier to implement (at least
partially and only for wizards) the inline_errors proposal. The error
message could be set instead of API through the properties as it is
done in my current patch. Not nice, but let say more acceptable than
hack I'm proposing now. The rest of the code from the patch would not
be needed - the buttons would be disabled as now and property text
would be shown in the wizard panel. WizardDescriptor would listen on
property changes and update the error text accordingly.

The potential problems I see:
* is everything related to inline_errors proposal clear from the
UI/HIE point of view?
* it is UI change and we are in UI freeze? Can it be still done?
* this change would eaten some space from each wizard dialog, but
almost none module will have time to take advantage of it and show
there some errors. The target chooser panel would of course use it to
solve problem reported in this issue.
* it has impact on the Documentation (Patrick see inline_errors
proposal in the URL field). Is that OK?

I will try to implement prototype tomorrow whether what I'm proposing
is feasible, but I would like to hear answers from UI team and Docs
team to my questions in the meantime. Thanx.
Comment 14 _ ttran 2003-02-13 22:03:53 UTC
> it is UI change and we are in UI freeze? Can it be still done?

Patrick would know the definitive answer.  My opinion is that this UI
change will have significant impact on Doc (there are screenshots in
many places, not only in users guide but also in various turorials)
and should not be done that late.  BTW this bug is there for long
time, it's much older than the report date.  This should be taken into
consideration whether or not we postpone the fix to the next release.
Comment 15 Patrick Keegan 2003-02-13 22:27:01 UTC
Actually, this looks OK to me. I can't imagine that screenshots would 
focus on the scenario of a user entering a duplicate file name. Am I 
missing something?

Bob, could you look at this as well? The link in the URL field gives 
an explanation of the change.
Comment 16 Bob May 2003-02-13 22:36:49 UTC
I don't see this, as Patrick implied, having an impact on existing
There are no existing screenshots that focus on the scenario of a user
entering a duplicate file name, which appears to be a focus of the
document in the URL.
Comment 17 _ ttran 2003-02-13 22:56:52 UTC
but does it change the look of the wizards even if no error message is

From a different perspective, we are late in the cycle, I would be
very careful with API changes.  Only if the change is _trivial_
Comment 18 Milos Kleint 2003-02-14 08:22:38 UTC
we've added something similar to the UI spec for inline messages (yes,
I've been inspired by that and I really hated my colleague's
JOptionPane.showMessage() calls within the wizard)

It might be useful, attaching pictures on how it looks and the actual
code (haven't stripped it off our app related stuff, but both files
are quite small and it should not be problem to find the right stuff.)

We use JLabel as the inline message showing component, since it allows
HTML formatting (looks nice however has the drawback that depending on
the text size it influences the size and layout of the wizard panel.
for now we can live with that)

the algorithm for showing/clearing messages is not bulletproof but
works so far in our scenarios.
Comment 19 Milos Kleint 2003-02-14 08:23:35 UTC
Created attachment 8947 [details]
example of error message
Comment 20 Milos Kleint 2003-02-14 08:24:20 UTC
Created attachment 8948 [details]
example of a HTML formatted message in the wizard.
Comment 21 Milos Kleint 2003-02-14 08:25:23 UTC
Created attachment 8949 [details]
sample code of the inlined error notification.
Comment 22 David Konecny 2003-02-14 08:54:34 UTC
Milos, thanx for your help! That's very similar to what I have in my
mind. The only difference is that I would like to implement it wouth
any new API and was thinking about using properties for communication:
if a string property is set the panel will display the string. if a
string property is reset the panel will clear the error. Not that nice
as your API, but as a "bufgix" I believe it is acceptable. Especially
in the fact that this solution should be more trivial than my current
message box patch. The string could contain HTML to change colors etc.

I'm going to write patch which would implement this idea. If
successful I will attach it to this issue so you can all try it.

Trung, I would like to evaluate this possibility. At the moment it
looks that it could be very trivial. Definitely more trivial than
message box patch.

Patrick, thanx for the info.
Comment 23 Milos Kleint 2003-02-14 09:10:27 UTC
there's one problem we've come across and it might be relevant to your

Imagine you have 2 fields only.
 in the first one user enters a wrong value, doesn't correct it and
moves to the second field.
 in the second field, enters a wrong value as well, we show another
error, which overlaps the old one.
user corrects the wrong entry in 2nd field, we clear the error message.
 --> but the first field is still not correct, but the message is not

The code I've send you doesn't handle that, since we've decided that 
we'll cache a last-entered correct value and will replace any error
value when the component looses focus.
however the PanelErrorNotifier Apis should be able to handle it.

re: without APIs, there's already a lot of client properties
everywhere, wich were added as a way to add stuff without adding APIs,
but in reality over time they became apis anyway. most of them are
declarative stuff though, which you set once, here we are talking
dynamic changes..
Comment 24 Jaroslav Tulach 2003-02-14 09:14:25 UTC
Created attachment 8950 [details]
Eliminates the dynamic nature of David's patch
Comment 25 Jaroslav Tulach 2003-02-14 09:18:38 UTC
I do not like the changing of closingOptions in David's proposal
because being too "dynamic". The best objects are immutable ones,
anyway. Thus I've attached a version that removes the need to change
closingOptions, it is just enough to fire properly annotated
(ErrorManager.USER, good localized message) IllegalStateException from
the attached buttonListener. If you choose to implement David's
proposal please prefer the exception to changing closingOptions.

Comment 26 David Konecny 2003-02-14 09:36:34 UTC
Milos, that should not be problem in our wizards I think. Each panel
has isValid method and this method should validate all fields in some
order and set error messages. In your example the error in first field
will be reported till it is fixed. Then the isValid should continue
with validating second field.

As for the API: I agree. Adding property _means_ adding API. The whole
wizards are based on properties so adding another one seems to me at
least let say consistent. Adding property is also less burden than
adding new API interface. It is also possible that this property could
be private for openide and documented to be not used by the clients
for NB3.5 as this is still bugfix. But I think there is no need for
such a restriction. Once there is better API, the usage of the
property can be replaced by APIs.

Yarda, thanx for the patch. I agree.
Comment 27 David Konecny 2003-02-14 10:30:58 UTC
Created attachment 8951 [details]
screenshot of patch in action
Comment 28 David Konecny 2003-02-14 10:31:53 UTC
Created attachment 8952 [details]
source code patch
Comment 29 David Konecny 2003-02-14 10:32:47 UTC
Created attachment 8953 [details]
binary patch
Comment 30 David Konecny 2003-02-14 10:40:05 UTC
I implemented first version. The screenshot, source code patch and
binary patch are attached. Put the binary patch into your
netbeans\lib\patches folder to try it. Currently only Target Chooser
panel uses this feature. All other panels have empty space at the
bottom. At the moment the plain text is used and by default line is
always red. If I used HTML the different font was used and sizing gets
complicated as Milos mentioned. But this could be hopefully solved
with the help of UI or in worst case we can stay with plain_red_text.

Please comment. If you look at the source code patch it is pretty
simple. Anybody can use this feature by settings one property
"WizardPanel_errorMessage". I propose to implement it this way.
Comment 31 Bob May 2003-02-14 22:44:47 UTC
The only issue I have is if the implementation of this changes the
look of a Wizard, irrespective of whether an error message is in place
in the Wizard at a particular point in time. If all Wizard Panels will
different once this is implemented (irrespective of errors, i.e. even
when no errors are written), then I have a major issue with doing this
change for 3.4.x, as it will affect Nevada docs. If the change is
targeted for 3.5, and the Wizard Panels will change irrespective of
whether an error is present, then the change is more acceptable.
BTW, I believe Jan Benway wrote the spec so that the Wizard Panel real
estate is not greatly modified when no message is present.
Comment 32 Jan Benway 2003-02-14 22:47:32 UTC
Right. The intention in the spec is that the wizard real estate is
only affected if the wizard in question uses the in-line error API.
Simply making the API available should not affect any wizard screenshots.

Any wizard that takes advantage of the API will change in size.
Comment 33 Marian Mirilovic 2003-02-17 08:55:03 UTC
*** Issue 31132 has been marked as a duplicate of this issue. ***
Comment 34 David Konecny 2003-02-17 10:59:47 UTC
Comment from

"I do a lot of error checking and displaying in my module was planning
to implement my own inline error display in the next version of my
module in both my wizards and property editing dialogs so I was
interested to read about this implementation. My concern is that this
new property would only apply to WizardDescriptors and not
DialogDescriptors so I would have to do my own implementation for my
dialogs which might look inconsistent with error handling in the wizard."
Comment 35 David Konecny 2003-02-17 11:44:38 UTC
Bob, the change is planned for NB 3.5 (means I will commit it into
NetBeans main trunk). Current implementation affect size of all wizard
pages without regard the error message is displayed or not. When no
error message is displayed there is always *empty* space at the bottom
at the right half of the wizard dialog which is reserved for error
message. If this is a problem there could be a way to say whether the
wizard panel uses inline errors or not and then only the panels using
this feature would be affected in its size.

HIE/UI people: do you support implementation I proposed? It is not
100% according to Jan's UI spec. The text is always red. It is also
supported only for wizards what can cause inconsistence in dialogs as
described in louise.avila comment. Let me know your opinion, suggestions.
Comment 36 David Konecny 2003-02-17 11:48:46 UTC
For the record discussion from openide@dev about implementation issues:
Comment 37 Patrick Keegan 2003-02-17 13:32:03 UTC
Bob, David came by my desk and confirmed my understanding of the 
change. In his implementation, the some of the panels would have 
slightly more grey space at the bottom  to make room for the error 
message. But there is nothing that would make the panels *noticeably* 
different -- no visible widgets, no new borders, so I don't think 
this is a problem for screenshots.

Another clarification, "3.4.x" now equals 3.5. 
Comment 38 jrojcek 2003-02-18 13:15:49 UTC
I have a few comments about the patch. Some of them are just a bugs,
some are UI issues.

1. Warning label is not shown when you invoke the wizard from the
contextual menu.
2. If the label is shown and you press "Previous" button the label is
shown in the previous panel too.
3. Current wording of the error label may be a problem as you are
referring to "already existing file", but the user is creating Java
Class, JPanel Form, etc. OTOH, existing file is the actual error, so
if we can't find better wording I am fine with the current state.
4. Anyway, comma should be at the end of the sentence.

Otherwise I think it looks good and solves the problem.

I would like Jan Benway to check the patch too, as she has written the
error handling proposal.
Comment 39 Jan Benway 2003-02-19 00:56:34 UTC
It looks pretty good to me. I see all the issues that Jano mentions,
above, although it seems that #2, that the message appears also on the
previous panel, is the most serious.

Ideally, I'd like to get away from the all-red text, but I see that
there are some difficulties in using HTML.

The problem is that all red may be unreadable by color-blind users, so
hard coding the text to red will not pass accessibility requirements.

Accessibility is part of the reason why the spec shows most of the
text in black, and only the leading words (Error or Missing Data) in
red. The other reason is that all red is kind of rude, especially in
the "Missing Data" case, where the error may appear when the user
first comes to the wizard page and hasn't even had a chance to fill
anything in yet.

I talked to Bruce Lee (visual design) about this, and if all of the
text must be a single color, we agree that having it be all blue would
be better than all red. All blue is more readable than the red used in
the patch (for all users) and blue is much less likely to cause
accessbility problems.

Bruce suggests using R=89,  G=79, B=191

Lastly, I would love to see this implemented for dialog boxes as well,
but I don't see a problem in doing it for wizards first and dialog
boxes a little later on.

Louise and others could still do a custom implementation for dialog
boxes for the time being.
Comment 40 David Konecny 2003-02-19 15:17:20 UTC
Thank you for your comments. I will change the color to Bruce's RGB
and fix all found problems. I will integrate the issue ASAP and close
the INF.
Comment 41 David Konecny 2003-02-20 15:32:04 UTC

Checking in openide/;
new revision: 1.104; previous revision: 1.103
Checking in openide/api/doc/changes/apichanges.xml;
new revision: 1.139; previous revision: 1.138
Checking in openide/src/org/openide/;
new revision: 1.79; previous revision: 1.78
Checking in ui/www/docs/ui_apis/wide/index.html;
new revision: 1.3; previous revision: 1.2
Checking in openide/src/org/openide/loaders/;
new revision: 1.95; previous revision: 1.94
Checking in openide/src/org/openide/loaders/;
new revision: 1.3; previous revision: 1.2
Checking in openide/src/org/openide/loaders/;
new revision: 1.52; previous revision: 1.51
Checking in openide/src/org/openide/loaders/;
new revision: 1.3; previous revision: 1.2
Comment 42 Lukas Hasik 2003-08-04 16:24:21 UTC
verified in nb35 FCS