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.
|Summary:||No feedback, nothing happens when entering duplicate file name|
|Product:||platform||Reporter:||Ana.von Klopp <avk>|
|Component:||Dialogs&Wizards||Assignee:||David Konecny <dkonecny>|
|Severity:||blocker||CC:||benway, bmay, davidjon, jrechtacek, jrojcek, jtulach, mkleint, pkeegan, thp, ttran|
|Issue Type:||DEFECT||Exception Reporter:|
|Bug Depends on:||23116|
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
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. 3. 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 OpenIDE/core.
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 arises.
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? Thanks, Ana
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 Solaris.
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 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 documentation. 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 dislayed? 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 situation. 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 shown. 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 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 look 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 firstname.lastname@example.org: "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: <http://openide.netbeans.org/servlets/BrowseList?listName=dev&by=thread&from=17093>
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
Implemented. Checking in openide/openide-spec-vers.properties; 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/WizardDescriptor.java; 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/Bundle.properties; new revision: 1.95; previous revision: 1.94 Checking in openide/src/org/openide/loaders/NewObjectWizardPanel.java; new revision: 1.3; previous revision: 1.2 Checking in openide/src/org/openide/loaders/TemplateWizard2.java; new revision: 1.52; previous revision: 1.51 Checking in openide/src/org/openide/loaders/TemplateWizardPanel2.java; new revision: 1.3; previous revision: 1.2
Comment 42 Lukas Hasik 2003-08-04 16:24:21 UTC
verified in nb35 FCS