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.
Issues based on NB version that Sun ONE Studio 4 is built on. (NB3.3.1) In the Explorer, C/C++/Fortran files should show its functions, classes, types in the JTree just as the Java nodes do. Functionality such as being able to jump to the source within the file by double clicking the method name,etc in the explorer should also be provided. This request is also supported by a user during a recent usability study on Sun ONE Studio 4.
The reason Java files show some internal data types is that there is a Java parser in netbeans. To get the same support for C, C++, and Fortran we would also need a parser. This would be a great feature but might open up Pandora's box. For instance, should ther parser know about conditionally compiled code? If so then it needs to get this information from a compiler. If thats the case then which compiler? At Sun I'm mostly interested in our compilers but other user's might prefer GNU or some other compiler. And that compiler may not provide the parsing in a usefull manner. Perhaps it would be best to take a very lightweight approach and ignore all preprocessor code and just parse the primary file. Alternatively, we could pass the file through cpp (based on semi-standard compiler options) and parse that output. Both methods have pros and cons.
We can solve the problem of conditional compilation when we have project support (of the 4.0 kind) for cpp. Then the compiler flags are known. In the absense of that (e.g. for people who continue to use Makefiles) we can do at least one of the following: (1) Simply let the user type in the macros themselves as a property (2) Infer the properties from inspecting the Makefile(s) I wrote a Makefile scanner in the 6.0 days as a prototype to see if I could import Makefile "projects" into the project. As far as macros and include directories were concerned, this worked well (including recursive make calls). But it might be acceptable to only support -correct- file scanning for files that are a member of a proper project.
[S1S-EVAL]
Since NetBeans 6.0, Java does *not* expand files and show their structure in the Project or File Explorer window. This data is shown in Navigator window instead. That's what we do now for C++. It's quite consistent with Java and NetBeans as such. If we change this to what is proposed, we won't be consistent (and, in my opinion, showing the file structure in the same window is much less convenient; other IDEs show that).
closed