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.
The Help button in the Options window transfers focus away from the selected node or property sheet and back to the Options window itself. That means that if you select any node and click the Help button, you'll get the org.netbeans.core.actions.OptionsAction null help ID. So effectively CSH for all Options windows nodes is broken, even though selecting the node and pressing F1 works.
This should be fixed on the property panel rewrite branch - as a fix for another bug, the help button is no longer focusable - so it shouldn't affect focus at all when you click it (this is okay, there is a keyboard shortcut - F1, so the button itself does not have to be accessible).
Property panel rewrite branch merged.
branch was merged but problem's still there.
org.openide.explorer.propertysheet.DescriptionPanel line 111: helpButton.setFocusable(false); It couldn't steal focus if it wanted to - it can't be focused. What do you mean?
OK, let me be more clear. Before the new window system and property sheet introductions, the Help button on the Options window displayed the help for the node that was selected. Now it just shows the help for the Options window. I also once got it to show the help for the node it was on (Ant Settings). It then got stuck on that help ID, so that no matter which node you selected and pressed F1 you got the help for Ant Settings.
Which help button - the one on the property sheet or the one at the bottom that says "help"? I have not touched the code that affects the help button in the options dialog. Nothing should have changed there.
The one at the bottom that says Help.
Reassigning this to Peter - winsys integration caused this bug. How to tell: Open View | Properties. Open the options window. Notice the main property sheet is not changing - the Options dialog no longer sets the global node selection. Either fix the help button to track the TTV's selected node or fix the options dialog so it will affect the global node selection. Maybe want an HIE option - there are now two help buttons. The one in the property sheet does work correctly; the one at the bottom of the dialog doesn't.
adding UI keyword and Jano as a CC.
Well, I don't know how it was before, but now it seems to me it is working correctly. 1) If you select some node in options and press F1.. you get the help connected to the node (if available). 2) If you press help button on options window you get the help about options dialog (doesn't matter what is selected there). You demand that in case of 2) you get the help to selected node.. but I think that's wrong, the help button is set clearly in context of entire dialog, not the explorer selection. How you would get the help to options dialog, just to rely it falls back when node doesn't provide some? Passing to Jano to decide.
Unfortunately, according to most tests, nobody knows about F1 or uses it. Besides, I think the information users are most likely to need help on is the properties, and not the Options window itself. The two help buttons look kind of weird right on top of each other but there were two help buttons in 3.5 too. I'm fine with HIE looking at this but IMHO this is a clear regression and should be returned to the way it worked before.
Sorry, inadvertently changed the subcomponent
My point of view: The "Help" button should be context sensitive to currently selected node in options tree. Presence of small help button in property sheet is just a side effect of reusing the property sheet component in this dialog. In a future, we would hopefully have a customizer panel with regular components (not the property sheet). In that case the help button would of course display help of the currently selected options category. Please, have a look at the Mozilla's Prefererences dialog, which has context sensitive help button. To improve access to the general options dialog help, it should probably be linked from each contextual help page shown in help window.
OK, that's what you desire. Now I will need to investigate the API, because I've got a feeling current DialogDescriptor API don't offer something like that... Do you know about another such dialog example where it works the desired way in NB? I decrese the priority, from my point of view this is far from being No1 problem now.
Sorry, I really consider this to be a regression from the previous state. It needs to be addressed. As a P3, this might easily slip through the cracks. P3->P2.
In my opinion this shouldn't be considered a regression. Option component was before as a separate floating window which managed its help button. Now it was changed, as it was required by spec, to dialog. Now the help button is provided by that dialog API impl.. I'm not sure at this moment, but it seems that API doesn't offer what you desire... anyway there are new circumstances, why then the regression? Are you going to fire a regression that it is not a floating window too? Also even if it is a regression, why P2? I think issues priority means its importance... and this is not the most important issue now, I'm sure. An argument that if it is p3 it wan't be solved sound silly.
I'm sorry that the spec did not anticipate the effect on the helpID behavior. However, that does not change the fact that it is a regression from the user's point of view.
guys, please don't argue over if it's P2 or P3, nor if it's regression or not. Help stops working, which is a serious problem. We should fix it even if it's P5.
I'm not arguing, that's OK if you think is P2. Help didn't stop working, it is still working, it is just about how it should work.
Fixed in [trunk] core/../actions/OptionsAction.java 1.58
Verified, thanks!!!