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.
Java node is missing its subnodes representing the classes, methods etc. That breaks one feature in the visual web pack. It is not possible to retrieve the new types to create the bean properties/methods. See the dependent issue.
I am not aware of any plan to bring back these subnodes. The bean supports revamp has been postponed probably after nb 6.0. See issue #90907. However new beans UI should differ from the old support. There will be a new navigator view displaying editor content as a bean (properties, ...). In order to create bean patterns the new Code Generate stuff will be used. Nowadays you can already generate getters&setters with Alt+Ins in the editor. Dusan could answer if he plans this to be pluggeable in nb 6.0.
There are AFAIK no plans to (re-)implement the subnodes for NB6.0.
*** Issue 101889 has been marked as a duplicate of this issue. ***
I don't see why this is considered showstoper for VW. Can someone specify what is the problem. All surveys we did here showed that the nodes in explorer are almost unused. And in the 5.5 state also almost unusable. Unless there is a really appealing reason this remains a won't fix for us.
*** Issue 98133 has been marked as a duplicate of this issue. ***
Issue # 98133 has several comments explaining the rationale for this request.
*** Issue 125532 has been marked as a duplicate of this issue. ***
We do not plan to have subnodes.
>We do not plan to have subnodes. As in, never again? Or just not for 6.1?
How can I open just the source editor for form files? With big form files, I need to wait a while until the Matisse parse and build the form. I wish a way to open easily and quickly the form source file. If you don't plan, so I think it is time to reconsider this approach.
hmichel: right-click on the form's node and choose "Edit" it should open the Source tab of the form.
Re. Greg: Never again.
*** Issue 133051 has been marked as a duplicate of this issue. ***
Yesterday, I authored 133051, today, I find it was a known issue and a feature you guys have decided not to re- implement. The arguments for keeping the feature seem patently obvious to me and issue 98133 clearly articulates this. A year ago, phrebejk said the feature was almost unused and there needed to be a compelling reason for re- implementation. Ok, here goes. It looks like the class expansion functionality was removed in favor of using the Navigator window. So, the ability to see the expansion of several classes at one time in the Projects window was removed in favor of seeing one class at a time in a separate window taking up more screen real-estate? The Navigator window's facility for showing inherited members is highly useful, true. Seeing parameter and returned object types certainly has value as does filtering the list by static and non-public members. However, the additional real-estate used on the screen and the necessity of each class viewed having to be re-expanded every time it is selected in the Projects window really kills the value of the Navigator window. In simple terms, it slows you down. The author of one of the other duplicates of this issue said it best--being able to see several classes expanded at one time in the Projects window makes it possible to quickly analyze an execution path. Having to shuffle through the Navigator window each time a class is selected simply adds drag to a process that was high-speed in NB 5.0. Was it not possible to simply add the types, inherited members, non-public, and static members to the Projects window expansion? This would have been an enhancement. The problem I mention here is further exacerbated by the inconsistency of the Back/Forward button in the editor view. I have always found it frustrating it does not simply work by showing the previous or following view location. This seems to work if I am following source calls in a call chain, but if I switch to a different class in the Projects window, a debug trace, or a call trace, the order is broken and, when I hit the back button to see something I just looked at, it takes me to the last location in my source trace. I don't know if this is a bug or a feature but having the expansion in the Projects window helps to aleviate this headache. I hope there was really compelling reason for taking out the class expansion in the Projects window and not simply that you felt it was superfluous. Removing functionality in a tool like this is a dangerous business, guys. While I will continue to use NB 6 because of some of the new features and the need to work with Java 6, this one change, alone, would almost be enough to make me stay with NB 5. I will simply be slower, now, and that is never a good thing under deadline. Netbeans is a great tool, guys. You've made a winner here. I use the CRiSP editor for much of my work and have for many years. NB is the first IDE I have used where I do much of my program editing. For my money, it is the best IDE since Borland's TurboPascal editor of the 80's. I have either used or analyzed all of them and NB is the best. Believe me when I tell you that removing useful functionality in such an efficient tool is NOT an enhancement. I don't know if any of you have seen the modern equipment used for cutting down trees. They have machines now where a guy sits in a chair and users levers to grab a tree at the trunk and cut it into several managable logs in seconds. There's no offense intended here, NB is good work. But, you've kindof replaced the tree cutting tractor with one guy and a chainsaw. I really hope you'll reconsider re-implementing this feature.