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.

Bug 24500 - Need ability to explore C/C++/Fortran nodes like Java nodes in Explorer
Summary: Need ability to explore C/C++/Fortran nodes like Java nodes in Explorer
Status: CLOSED WONTFIX
Alias: None
Product: cnd
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: Vladimir Kvashin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-06-06 21:51 UTC by Ann Sunhachawee
Modified: 2007-12-18 14:55 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ann Sunhachawee 2002-06-06 21:51:28 UTC
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.
Comment 1 _ gordonp 2002-07-15 22:38:45 UTC
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.
Comment 2 Torbjorn Norbye 2002-07-16 09:40:44 UTC
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.
Comment 3 Jan Chalupa 2002-10-27 17:46:57 UTC
[S1S-EVAL]
Comment 4 Vladimir Kvashin 2007-12-17 13:31:26 UTC
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).
Comment 5 dnikitin 2007-12-18 14:55:07 UTC
closed