| T O P I C R E V I E W |
| wstanley |
Posted - Dec 19 2006 : 5:56:41 PM
Using VS2005 and VA 1539, specifying an include path for a project that use a VS2005 macro like $(IntDir) or $(SolutionName) and specifying a #include that will find a file in that directory causes VA not to be able to follow the include (is not able to identify the included file). |
| 15 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Jan 15 2007 : 12:42:25 PM
For future reference if you want to send me files then simply submit them via the form:
http://www.wholetomato.com/support/contact.asp
including this thread ID or URL in the description, so we can match it up.
I am happy this problem has gone away, this is always a good start. As to what was causing it, I really am not sure what to say. It is almost as if there was a dead explorer process, or something like that going on.
Certainly if you run into new problems then don't hesitate to contact us  |
| wstanley |
Posted - Jan 14 2007 : 8:40:47 PM
I have restarted the computer during the course of today, and as of now, I am not seeing the problem of how VS2005 is opened affecting include file lookup... I don't know what's going on anymore, so I guess this part of the problem can be ignored until (if) it comes back. |
| wstanley |
Posted - Jan 14 2007 : 5:37:01 PM
That all sounds right, but I didn't bother trying with 2 IDE's at once, I was just opening one, testing, close, try the next case.
I'm using WinXP SP2, VS2005 SP1 and VA 1543 (1544 is not available to us yet). There are no other plug-ins installed. Is it worth sending you a copy of the project I am using and some screen shots? (I will need an email address to send a zip file) |
| feline |
Posted - Jan 12 2007 : 2:35:36 PM
I had not run any tests at the time I replied, I wanted to clear up any confusion first. I don't mind running a pile of tests, but it is always best to try and test the right thing, it saves everyone time and trouble in the long run
Which OS are you using?
Do you have any other plugin's installed?
I have changed my solution so that additional include directory is $(IntDir) with NO trailing slash. The test header has been placed into the Debug directory, and I am still using the debug configuration.
I have tried opening the solution via:
* IDE file menu -> recent projects
* IDE -> recent projects list on the start page (pressing Space to select the item)
* Pressing Enter on the SLN file using Powerdesk 5 (a replacement for Windows Explorer)
* Pressing Enter on the SLN file using Windows Explorer, launched via Windows Key + E
I have tried all of these more than once, with one IDE open or two IDE's open. I see the same result every time. I place the caret on the #include "" line and the correct file name is shown in the VA wizard bar.
I press alt-g and VA takes me to the correct file.
This is with and without this test header file open when the solution loads.
The only difference I can get is that if I open a second IDE I am told that the IDE cannot write to the NCB file, which is because the first IDE will have locked it. This did not make any difference to VA's alt-g behaviour.
This is testing on win2k SP4, VS2005 SP1, VA 1544.
Am I missing something obvious here? |
| wstanley |
Posted - Jan 10 2007 : 10:52:30 PM
quote:
Originally posted by feline
What do you have your C++ additional include directories set to? $(IntDir) would make sense, but we were chasing $(IntDir)\\test
I should have been more explicit and said that I had now added $(IntDir), I just assumed you would infer it... With the workaround of added required directories to PVCS, I though (at least for the moment) that we had solved the case of using $(IntDir)/test.
quote:
I would not expect how you open the solution to matter.
Neither would I, but did you try it? I just did it again to make sure... Modify the project so that testClass.h is in $(IntDir) and modify the include directories appropriately. Then open two VS 2005 instances, one via the open action on the solution file (sln) and the other one by opening VS, and then opening the solution via the File menu. In the instance that is opened via explorer, VA will not find testClass.h.
quote:
The "environment" variables changing while the IDE is open, I am not surprised that VA does not handle this. For now I am inclined to list this as a known limitation.
I am happy with that as it is only very minor, but I though I should mention it for completeness. |
| feline |
Posted - Jan 10 2007 : 07:53:30 AM
What do you have your C++ additional include directories set to? $(IntDir) would make sense, but we were chasing $(IntDir)\\test
I would not expect how you open the solution to matter.
The "environment" variables changing while the IDE is open, I am not surprised that VA does not handle this. For now I am inclined to list this as a known limitation. |
| wstanley |
Posted - Jan 09 2007 : 8:25:45 PM
Using watch for externally modified files does not affect this problem.
We are using PVCS, so I now have it setup to create the subdirectories under Debug (this works quite well as a work around), but I have now noticed that VA behaves differently when the solution is opened by the default actions (open the solution file from explorer) and opened for the VS File menu. When opening from explorer, files that already exist (or are added later) in the Debug directory (excluding any subdirectories, these still work fine) are not found.
When opening from the file menu, the files in the Debug directory are only noticed if the directory already exists (so what I thought previously about it working for the intermediate directory strait off is wrong, it is just the same mechanism that is working for the other subdirectories).
Another very minor problem is that when changing from Debug to Release builds, VA does not pickup the fact that the include directory has changed, so using ALT-A still goes to the version of the file generated for the debug build. VA sticks with whatever the path was for the selected build when the solution was opened. |
| feline |
Posted - Jan 09 2007 : 08:12:37 AM
The Visual Studio check, some things can confuse this check. For example I have seen MS Excel trigger this warning, even though the IDE is not running.
You could try turning on:
VA Options -> Text Editor -> C/C++ -> watch for externally modified files and reparse when necessary
and see if this makes any difference to VA finding this directory.
I am not completely surprised that creating the directory after the IDE has loaded confuses VA. This is probably a situation we never considered.
When you recompile from a clean slate is there some procedure you follow to get to this clean slate? I am wondering if there is any form of script or batch file involved, or something like a CVS checkout, so that these blank directories could be added to the procedure, so they would always be there. |
| wstanley |
Posted - Jan 08 2007 : 5:35:54 PM
I also upgraded VA to 1543, but I was only able to get it to install by getting it to ignore the VisualStudio check. Even after a reboot, it insisted that VS2005 was running... It still behaves the same. |
| wstanley |
Posted - Jan 08 2007 : 5:32:24 PM
I think we are seeing the same thing, but I am not restarting the IDE after creating test\\testClass.h. If the Debug\\test directory exists at the time the IDE is started, any new files added to the directory will be found. If the directory is subsequently deleted and recreated, it is still fine. If the directory does not exist at the time the IDE is started, no amount of time is long enough for VA to figure it out... So for the moment at least, it is something I will need to look out for whenever I recompile from a clean slate. |
| feline |
Posted - Jan 08 2007 : 09:47:20 AM
So far I am not seeing any problems. I now have the following:
VS2005 SP1 with VA 1543
This is a C++ console project.
I have added the line:
#include "testClass.h"
to my cpp file. OFIW does *not* list "testClass.h" assuming it is not open, so I am quite happy that this file has not been added to the project.
The complete path to this file is:
C:\\src2005\\Console\\App1\\Debug\\test\\testClass.h
the C++ additional include directory is set to $(IntDir)\\test
the project compiles. I have restarted the IDE, so VA has had plenty of time to catch up with things.
When I place my caret in the file name on the #include line the VA wizard bar shows C:\\src2005\\Console\\App1\\Debug\\test\\testClass.h and alt-g jumps to this file quite happily.
This seems to match your description, unless I am missing something obvious. |
| wstanley |
Posted - Jan 07 2007 : 6:10:43 PM
Sorry, I have given you a bum steer, I will blame it on being well into the silly season. $(SolutionName) is not a good example macro for this problem, it should have been $(ConfigurationName), which is actually the default value for $(IntDir). $(IntDir) is quite applicable however.
Continuing with your example, this works fine while the file to be included is in any directory referenced by the project via a project file (I had not noticed it was working in this case previously). It also works if the generated file is in the intermediate directory (another case I had not noticed), but if the file is in a sub-directory of the intermediate directory, (or any other directory that is not directly referenced via a project file in the directory) it does not work. So this shifts the problem from the macros to whatever the mechanism it is that determines what directories that need to be monitored for include files (maybe the specified additional include directories should be added to this list).
To see the problem as I have been seeing it, move the testClass.h file from the App1\\Console directory to App1\\Debug\\test (assuming a Debug build), remove testClass.h from the project and change the include directory to $(IntDir)\\test. Remember this is representative of a generated include file that is generated into the intermediate directory, it would be somewhat annoying to have to add a new reference to the file in the project for each build type created just so that the goto include file function will work. |
| feline |
Posted - Dec 21 2006 : 11:14:21 AM
This makes sense.
What exactly are you putting in the additional include directories setting? I have a C++ solution called "Console" which contains a single project called App, giving me the files:
C:\\src2005\\Console\\Console.sln
C:\\src2005\\Console\\App1\\App1.vcproj
I have set the C++ additional include directories to the string $(SolutionName) and created the directory:
C:\\src2005\\Console\\App1\\Console\
I have created a zero length file:
C:\\src2005\\Console\\App1\\Console\\testClass.h
in my project the line:
#include "testClass.h"
compiles perfectly. When I place the caret into this file name VA lists the correct full path for this file in the definition field, and alt-g goes to this file.
This is using VS2005 with VA 1543. I have restarted the IDE after changing the additional include directories setting to make sure everything is up to date.
Am I doing the same thing as you? |
| wstanley |
Posted - Dec 20 2006 : 5:52:45 PM
C++, resource and MIDL compiler additional includes directories.
By default, the intermediate file directory name is the SolutionName (and VC copes quite well, even when there are spaces). To improve the build process (and time due to unnecessary rebuilding) with switching between debug and release (or any other type of build), I am trying to use the intermediate directory as the destination for any generated source files, and to compile the source (or include the source) from the intermediate directory via the include mechanisam. This is working fine, but VA then does not know where the included file is... |
| feline |
Posted - Dec 20 2006 : 5:37:23 PM
Are you setting these in the projects C++ additional include directories?
Which IDE macro's are you using? $(SolutionName) seems like an odd choice to me for the include directory name, since this is not automatically a very good path name. |
|
|
