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.
Creating an umbrella issue for collecting issues for disabling help buttons in the New File wizard.
Here's an alternative approach: Write a generic New Java File (New Java-Related Class? General New Java Class? New Java Class (General)?) CSH and map it to org.netbeans.modules.java.project.JavaTargetChooserPanel. I think this ID is popping up because lots of engineers are using the same template for a new Java class wizard and this help ID is enabled in the template. Any wizard that is altered significantly from the template should have its help ID changed to a unique value, and we'll write a unique CSH for it. However, a quick look through Swing GUI and JavaFX new class wizards shows no changes from the generic template. The template is just Name/Location/Package and doesn't really need Help IMO but it might be easier for us to make one change to JavaHelp than for every engineer who owns a New Java Class wizard to disable their help buttons. No solution until after 7.1, anyway.
I think that such a generic topic would be so generic as to be uninformative/useless/frustrating. A user clicking on a help button for eg New Interceptor Binding Type would expect information relevant to that file type, not something generic that says click OK to create a new file. In most cases the description in the wizard already provides some information about the file type. In my opinion we should not create a topic just because there is a help button, but write topics where one is needed. If no topic is needed we should remove the button.
Yeah, the only way it would be at all helpful to the user is if the help topic included links to topics on Java classes, Swing containers, JavaFX, etc. But the links would have to go to some top-level help page for each tech, or link to so many pages that it would be a confusing mess. Well, it was just a suggestion.
adding more issues to as dependencies
(In reply to comment #2) > I think that such a generic topic would be so generic as to be > uninformative/useless/frustrating. A user clicking on a help button for eg New > Interceptor Binding Type would expect information relevant to that file type, > not something generic that says click OK to create a new file. +1 ... Do you plan to work on that for 7.2 ?
(In reply to comment #5) > (In reply to comment #2) > > I think that such a generic topic would be so generic as to be > > uninformative/useless/frustrating. A user clicking on a help button for eg New > > Interceptor Binding Type would expect information relevant to that file type, > > not something generic that says click OK to create a new file. > > +1 ... Do you plan to work on that for 7.2 ? This would be the ideal to have a short description for each file type in the help topic for the wizard. It would not be impossible to do this. But I question if the help topic invoked from a help button in the UI is the proper place to describe concepts such as "what is a servlet" and "why would I want to create a servlet". It is a question of what type of information is expected there. Usually a help button in a UI is there to help the user with the UI, especially when it is not clear. In the case of new file wizards, most do not require clarification about what eg Location or Class Name means. The ideal would be if each new file wizard had a unique help id and unique associated topic, with a short description of what and why about the file type, and then a link to some place with more information about the subject. Is this achievable in the 7.2 timeframe?
So after some discussion it was decided that the best course of action would be to disable the help buttons on the simple New File wizards, ie those that are basically one page and where the only editable fields are the file name and location. All other New File wizards should have help buttons enabled and corresponding CSH help. Help buttons should not be mapped to TOC topics.
*** Bug 211316 has been marked as a duplicate of this bug. ***
These all seem to be fixed now