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.
Created attachment 117430 [details] snapshot of include directive. With recent versions of NB, I get many more syntax errors flagged in the IDE than I did with earlier versions. I used to deal with this by removing the cache (which no longer exists) or reparsing the project. But now the errors remain. The attached image shows the "analyzed system include paths", for debugutil.hh, which appear to be the default paths, and do not include the project's configured include paths. The configuration is DebugLinux, and I'll attach the configuration.xml for the project. Product Version: NetBeans IDE Dev (Build 201203210400) Java: 1.6.0_23; Java HotSpot(TM) Client VM 19.0-b09 System: Linux version 2.6.35.14-106.fc14.x86_64 running on i386; UTF-8; en_US (nb) User directory: /home/toddb/.netbeans/dev Cache directory: /home/toddb/.cache/netbeans/dev
can you, please, attach mentioned configuration xml and provide the following screen shot: - select problematic file in project view - open it's Properties - for Include Paths, click on "..." and attach here what is displayed in dialog Thanks, Vladimir.
Created attachment 117490 [details] configuration.xml for the confused project
Created attachment 117491 [details] diff between a confused nbproject and a not-so-confused nbproject
Created attachment 117494 [details] View of the same file (basicutilfscommon-v3.cc) in a different source tree.
Sorry. Forgot to add the promised configuration.xml. Today I noted that in a different svn working copy (with identical source files) that the editor pane for the same file was much less decorated with syntax errors. I've attached the diff of the two nbproject directories, which is basically no difference. I've also attached a screenshot of the editor pane looking at the same file in the less confused project. These are both working copies on the same source code base. But since the syntax view of the same file is different, it follows that something else is also different. The attachments above show that the configuration is not substantially different, and in fact the differences that exist come from changes introduced by NB as it views the directories.
Ah! Operator error, but one that NB should help me catch. Ignore everything above. This has happened to me a number of times and it always bugs me. So let's say I have project group G1 and project group G2. Both groups have the identical set of projects in them, but they are in different source trees. For example G1's project group includes projects P1, P2, P3. And G2's project group has the same three projects. Of course P1 contains a number of source files, F1, F2, F3, ... etc. And P2 contains the same files. So here's the problem: I have G1.P1.F1 open in the editor, and then I switch to project group G2, and all the projects and files in G1 are closed... except for G1.P1.F1. Visually I cannot see the difference between G1.P1.F1 and G2.P1.F1, and I don't know why the file remains open. I am pretty sure the file has not been modified (and if it did NB should ask me if I want to save it before closing it). It may be that the working copy of G1.P1.F1 has been modified WRT to subversion. A screenshot of the two views is attached. In any case NB should never, ever keep G1.P1.F1 open when I switch to G2. Certainly I can defeat this by opening a file in the editor that belongs to a different source tree. But I rarely do that, if ever. What would you think of having NB check whether the open files belong to the projects being closed?
Created attachment 117495 [details] screenshot of two files, one in the project, one not
Correction: > Of course P1 contains a number of source files, F1, F2, F3, ... etc. And P2 contains the same files. Should be: Of course P1 contains a number of source files, F1, F2, F3, ... etc. And P1 from the project group G2 contains the same files.
Igor, please, investigate
Cannot reproduce the issue, described in Comment 6. Probably I'm using incorrect testcase. Here are my steps: 1. Create Welcome sample with "Welcome" name and save it to /tmp/111. 2. Create Free Group with default options and name it G1. 3. Switch to (none) group. 4. Create Welcome sample with "Welcome" name and save it to /tmp/222. 5. Create Free Group with default options and name it G2. So for now we have: - Welcome project in G1 group living in /tmp/111/Welcome - Welcome project in G2 group living in /tmp/222/Welcome 6. Switch to G1 and open welcome.cc. 7. Switch to G2 -> welcome.cc from G1 is closed. 8. Open welcome.cc from G2. 9. Switch to G1 and check editor tab hint -> it is "/tmp/111/Welcome/welcome.cc". 10. Switch to G2 and check editor tab hint -> it is "/tmp/222/Welcome/welcome.cc". 11. Close welcome.cc from G2 and switch back to G1 -> welcome.cc from G1 has been opened. So everything is working as expected. I don't have setup Subversion server, so I've used local Mercurial repositories for additional testing. I've placed both Welcome from G1 and Welcome from G2 to different repositories and tried some of the above steps -> everything is working the same way. Could you please try the same scenario by userself. And if it is also works for you provide some other scenario I can reproduce.
Another attempt. Now with managed projects. Still cannot reproduce the issue. Here are the steps: 1. Create Quote sample with Quote_111 name in NetBeansProjects directory. 2. Build it, drag resulted binary to IDE and create unmanaged project in /tmp/111. 3. Close Quote_111 and create Free Group with default options and name it G1. 4. Switch to (none) group. 5. Create Quote sample with Quote_222 name in NetBeansProjects directory. 6. Build it, drag resulted binary to IDE and create unmanaged project in /tmp/222. 7. Close Quote_222 and create Free Group with default options and name it G2. So for now we have: - quote project in G1 group living in /tmp/111/quote with sources in NetBeansProjects/Quote_111; - quote project in G2 group living in /tmp/222/quote with sources in NetBeansProjects/Quote_222. 8. Open some files in both groups and try to switch between groups -> all correct files are opened/closed. 9. Add /tmp/test1.c to quote from G1, and /tmp/test2.c to quote from G2. 10. Open test1.c in G1, switch to G2, open test2.c, switch to G1, switch back to G2 -> test1.c is active if G1 active, test2.c is active if G2 is active. 11. Add /tmp/111/test.c to quote from G1 and add /tmp/222/test.c to quote from G2. Open them both in corresponding groups. 12. Switch between groups several times -> always correct test.c is opened. 13. Try to close and open both quote's -> no files are left opened, switching is working fine after re-opening. 14. Create logical folder named test in both quota's and add /tmp/333/111/test.c to G1 quota's and /tmp/333/222/test.c to G2 quota's test logical folder. 15. Switch back-and-forth -> everything working as expected. I guess we need to know a little bit more about your projects and workflow to reproduce this.
Todd, Could you please try my testcases. I cannot reproduce the issue, so probably it is already fixed in latest 7.2 builds. But another option that you projects have some peculiarities that I haven't tried. In that case it would be great have to some toy project I can reproduce the issue on. Regards, Igor
Sorry... I haven't been able to get back to working in netbeans. I should note that I don't know when these files remain open. I am frequently shifting between project groups (which for me are different svn working copies of the same software) and since I have many files open, I don't notice the occasional file from the wrong group until much later. You could be quite right, that it is fixed in the latest version. If I can't come up with a repeatable test, we should close this. Thanks Igor.
Ah! Here's one method (although it does not belong here): Have two project trees for the same project; call them copy A and copy B. So of course A and B have the same relative path names, but the absolute paths are different. For example copy A might live in ~/src/copyA and copy B in ~/src/copyB. Open a project in copyA, and open a file in the project; say... ~/src/copyA/foo.cc. Set a breakpoint somewhere in ~/src/copyA/foo.cc. Switch to the same project in copy B (all the files close nicely)
Ah! Here's one method (although it does not belong here): Have two project trees for the same project; call them copy A and copy B. So of course A and B have the same relative path names, but the absolute paths are different. For example copy A might live in ~/src/copyA and copy B in ~/src/copyB. Open a project in copyA, and open a file in the project; say... ~/src/copyA/foo.cc. Set a breakpoint somewhere in ~/src/copyA/foo.cc. Switch to the same project in copy B (all the files close nicely). Now double click on one the breakpoint (in the breakpoint window) that shows "foo.cc". This opens up foo.cc in copyA, not copy B. The point here is not that breakpoints should be per project (which they should be as described in Bug 175475), but rather it is possible to get files open from a different build tree that shouldn't be. I know, I know, I should be able to open any file anywhere. I don't know the right solution. In this case, I did something that caused the unexpected... that's bad. Now how does the ide sort out what is unexpected and what is not?
The following scenario reproduces the issue: 1. Create Welcome in /tmp/111 2. Add it to Free Project group G1. 3. Switch to group (none). 4. Create Welcome in /tmp/222 5. Add it to Free Project group G2. 6. Open welcome.cc from G2 and set break point in it. 7. Switch to G1. 8. Open Breakpoint window and click on the breakpoint -> welcome.cc from G2 will be opened. If welcome.cc is opened then two files with the same names will be opened at the same time. I'm closing this as a duplicate of 175475. *** This bug has been marked as a duplicate of bug 175475 ***