| T O P I C R E V I E W |
| maxim2000 |
Posted - Oct 01 2008 : 05:38:47 AM
VA parses stdlib.h from IDE (or VA options) include directories. But project's include directories point to a different location (to DDK). So, Alt+G works incorrectly.
Should I make some additional customizations or this is a bug? |
| 7 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Oct 11 2008 : 08:57:41 AM
The current build configuration, part of the problem here is what VA is designed to do. Consider the common situation where you have:
#ifdef DEBUG
// some code
#else
// some other code
#endif
or the more interesting
#ifdef LINUX
#endif
VA is designed to be active in, and helpful with all of this code, regardless of whether it is active or not. In the second case you are most unlikely to ever see LINUX live in any build configuration under Windows 
The idea of scanning these directories, I am not quite sure what to say. My concern is that we have only just made a change to how VA scans directories looking for header files. We had a user where VA was rather hard to use, since VA was spending far to much time searching for header files in far to many directories. This was causing the whole machine to run very slowly, and made typing slow and difficult.
You seem to be asking for VA to reintroduce this "problem" behaviour. VA has already found "stdlib.h", and has no reason to assume there is a 3rd, 4th or 10th version to be found. If every possible directory has to be searched for every possible header file (which is one logical consequence of this idea) then for large solutions this could get very nasty. |
| maxim2000 |
Posted - Oct 06 2008 : 09:46:56 AM
I used #include "" form. It also looks into directories of /I option.
Another idea is to offer all directories from all build configurations. It is even better than using current config only. On a large solution it takes too long to switch the build config. The pleasant side effect is VA will see additional symbols, which defined on project settings level (e.g. preprocessor definitions - /D option). Opening files for VA only will also break down.
Multiple OS's is a problem which can be scheduled :) May be VA options will help.
Why VA can't see IDE settings like current build configuration? AFAIK, IDE editor is something like special component which can be embedded into IDE. And it highlights symbols depending on current build config. Is VA a component of different type? |
| feline |
Posted - Oct 03 2008 : 6:07:52 PM
Are you using a:
#include <>
or
#include ""
line? These are different with regards to the directories that should be searched.
I have tried this with the line:
#include <stdlib.h>
added to a cpp file and the new file "C:\\src\\stdlib.h" which VA can find via the solutions "Additional Include Directories" setting. VA does not automatically offer me this file as a destination, but once VA has found and parsed this extra copy of "stdlib.h" then it does offer it as a destination.
Considering the projects include directories first is an interesting idea, but it also has problems for VA. It is quite possible to have different include directories set for release and debug modes. VA does not know which mode you are using. Also consider people who are targeting multiple OS's.
The compiler gets to make certain simplifying assumptions that we are not able to make. |
| maxim2000 |
Posted - Oct 02 2008 : 10:08:38 AM
I mean that project's includes should be considered foremost. And IDE works like this.
In which order does VA iterate directories to find a symbol? There are several sources: IDE settings, project settings and VA settings. It seems that VA begins a search from IDE or VA settings.
Anyway there are no paths from project settings in the context menu of "Alt+G" command.
It is easy to reproduce the behaviour. Just copy stdlib.h to C:\\Temp and add the path to project settings. Now Alt+G doesn't see the header in C:\\Temp (try to find qsort() or any other). |
| feline |
Posted - Oct 02 2008 : 05:22:54 AM
Adding custom sets is difficult, since the sets are actually picked up from the IDE, and installing certain SDK's adds new sets to the IDE, which VA then picks up and supports.
If you need to change the directories listed in the platform list on a regular basis then you can do this by changing the values in the registry keys where VA stores this information. A couple of .reg files that you import to change the keys is one simple approach.
I don't understand your comment about project settings. The project settings are used and supported, but these are added to the stable include directories, they do not replace them. This is how the IDE its self works. Most projects do not contain any additional include directories, relying totally on the IDE's stable include directories to find the required header files. |
| maxim2000 |
Posted - Oct 01 2008 : 11:44:27 AM
Well, I mentioned stdlib.h for example. There are a lot of files with identical names at different locations. I tried to comment all the includes in StdafxVa.h but it takes no effect. Even after symbol databases were rebuilt.
The second solution is helpful for me. Thank you very much.
It would be nice to have possibility to create custom sets with editable names like "DDKIncludes" etc.
Though, I don't know why VA can't manage with project settings. Just try to use another SDK/DDK. I think that VA "Projects Directories" is not intended to solve problems like that. |
| feline |
Posted - Oct 01 2008 : 06:06:58 AM
VA understands project settings for me. One thing that might be going on here is that VA uses the file:
C:\\Program Files\\Visual Assist X\\Misc\\StdafxVa.h
to help initialise the symbol database. This file is just a list of include lines, for header files to parse. You could try removing the stdlib.h entry from this file.
Alternatively you could try setting:
VA Options -> Projects -> C/C++ Directories -> Platform = Custom
and pointing VA at the directories you want it to use. Please note that both of these actions will be global, they will effect all solutions you open on this machine. |
