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.
I'm running Forte Enterprise Edition, which has a huge number of modules. I want to disable most of them, since I'm only using a few of them. I use the Setup Wizard for that. When I press Finish, I get this dialog telling me that in order to disable (module list here), I have to also disable (other module list here). Since I've disabled 20 modules or more (or, if I've disabled one key module, such as say the basic java support module, such that the "must also disable" list is long), the resulting dialog is too tall to show on my desktop. Thus the "OK" button is off screen. I had spent 20 minutes customizing my module selection (like I said, Enterprise Edition has a large number of modules!, and with the combobox boolean selector it takes multiple keypresses for each disable operation) so this is a bit annoying. I think the contents needs to be put inside a scrollpane. See screenshot for an example of what I mean. (I will attach that next).
Created attachment 4710 [details] Screenshot showing the problem with the module disable confirm dialog
It's a problem, all right. ModulesBean just creates a NotifyDescriptor.Confirmation with a long string. NbPresenter is responsible for physically laying it out in a dialog. Of course ModulesBean could work around this if necessary by creating a Swing component (textarea?) in a scrollpane, but it would be preferable if NbPresenter handled this sort of thing more generally, I guess.
anyone already working on it? I am taking over.
a JScrollPane is inserted in between iff the preferredSize of the message pane either has the width > 600 or height > 400. The result does not look very pretty, but if you have so many charaters in the message text it's already ugly. At least now the dialog is usable.
It seems like fix of this issue caused issue 21041.
someone (jchalupa?) added 3.3.2_CANDIDATE keyword. Justification?
Yes, I've attached the keyword. It seemed to me that the fix was not complicated and might improve the user's experience (especially when the user needs to customize a product consisting of many modules such as FFJ). Also, the bug is a P2 so it seemed to be a good candidate for fixing in the next bugfix release. Feel free to push back if you disagree.
> It seemed to me that the fix was not complicated only that I created a significant regression (issue 21041) during fixing this bug <sigh>
For FFJ-EE the module number is so large that this bug is a lot more likely to occur. We're pushing module-disablement as the primary performance-tuning method when users complain about slow performance. With this bug that's problematic.
Created attachment 5295 [details] binary jar patch for release33/orion_fcs, put it in lib/patches
Created attachment 5296 [details] diff against release33/orion_fcs
Please test the patch for release33/orion. Dangerous change, affects every Dialogs/Wizards in the IDE
Patch verified in EE020404_2. Any regression such as 21041 wasn't observed.
integ'ed into orion_fcs
verified in 020408_1
Resolved for 3.4.x or earlier, no new info since then -> closing.