| Author |
 Topic  |
|
|
KirillMueller
Ketchup Master
72 Posts |
 Posted - Dec 30 2007 : 02:28:58 AM
|
I am using Visual Assist for quite some time now, mostly for C++ projects. I always use the latest build of VAX. It seems to me that, during the past year, the usefulness of autocomplete, autosuggest and goto symbol has gradually decreased. It's just that I remember that Alt+G used to work almost always, now it works sproadically. Recently, I had to type some 20-char symbols by hand, which is something I supposed VAX would save me of... Also, memory consumption seems to be far too high -- sometimes the virtual size of devenv.exe goes as high as 2 GB.
Now, my codebase evolved quite a bit over the past year, too. Chances are that the current version of VAX work better with previous versions of my codebase, however, this doesn't help me much.
I do rebuild VAX's symbol DB regularly. I just reproduced an error in goto symbol that occurs right after rebuilding DB -- VAX just won't recognize the method.
The above is just a list of (remarkably sad) impressions I've had from VAX lately. Unfortunately, I couldn't find the time to write it down until now. I love the product and I would like to continue using it, it's just not as useful as it could be at this moment.
Did somebody else notice similar problems?
Support: How can I help you help me improve my experience?  |
|
|
feline
Whole Tomato Software
United Kingdom
18948 Posts |
Posted - Jan 02 2008 : 08:43:44 AM
|
Memory usage of 2 gig, that normally indicates that VA's symbol database is corrupt. If this is the case then alt-g is not going to work very well, if at all, and you will see quite a few other problems as well.
Which IDE and version of VA are you using?
Do you ever run more than one IDE at the same time?
Is your source on a local drive, or some form of mapped or network drive?
If you rebuild VA's symbol database, how long is it before you start seeing problems? Minutes? Hours? A few days? A couple of weeks? |
zen is the art of being at one with the two'ness |
 |
|
|
KirillMueller
Ketchup Master
72 Posts |
Posted - Jan 02 2008 : 09:18:27 AM
|
IDE: VS2005
VAX: Latest
Sometimes more than one IDE
Source and DB on local drive in my local profile, but:
I run Vista. I have redirected the C:\\Users folder to E:\\Users using a NTFS junction. E: is a separate partition on the same disk. Logically, the profile still resides in C:\\Users.
After rebuilding, it takes something like hours or a few days before problems occur. Sometimes, the problems even occur right after rebuilding the DB. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18948 Posts |
Posted - Jan 02 2008 : 09:25:27 AM
|
Can you please go to:
VA Options -> About -> Copy Info
and paste the details (from the clipboard) into this thread. This will give us the basic information about your setup.
I would not expect the NTFS junction to be causing any problems, but I suppose it is possible it is a factor.
Approximately how large is your solution? If you open the OFIS dialog the title bar lists two numbers. The first number is the number of files currently showing in the (filtered) list and the second number is the total number of files in your solution.
Do you have any other IDE plugin's installed? |
zen is the art of being at one with the two'ness |
|
|
|
KirillMueller
Ketchup Master
72 Posts |
Posted - Jan 02 2008 : 11:54:03 AM
|
VA_X.dll file version 10.4.1624.0 built 2007.12.07
Licensed to:
VA X: *** (1-user license) Support ends 2008.07.09
DevEnv.exe version 8.0.50727.867
msenv.dll version 8.0.50727.867
Font: Consolas 17(Pixels)
Comctl32.dll version 6.10.6000.16386
Windows Vista 6.0 Build 6000
2 processors
Platform: Win32
Stable Includes:
C:\\Program Files (x86)\\Codejock Software\\MFC\\Xtreme Controls v11.2.0\\Source;
C:\\Program Files (x86)\\Codejock Software\\MFC\\Xtreme CommandBars v11.2.0\\Source;
C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\include;
C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\atlmfc\\include;
C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\include;
C:\\Program Files (x86)\\Microsoft Visual Studio 8\\SDK\\v2.0\\include;
C:\\Program Files (x86)\\Codejock Software\\MFC\\Xtreme CommandBars v11.2.0\\Source;
C:\\Program Files (x86)\\Codejock Software\\MFC\\Xtreme Controls v11.2.0\\Source;
C:\\Program Files (x86)\\Common Files\\microsoft shared\\VBA\\VBA6;
C:\\Program Files (x86)\\Python25\\include;
Other Includes:
Stable Source Directories:
C:\\Program Files (x86)\\Codejock Software\\MFC\\Xtreme Controls v11.2.0\\Source;
C:\\Program Files (x86)\\Codejock Software\\MFC\\Xtreme CommandBars v11.2.0\\Source;
C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfc;
C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfcm;
C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\atl;
C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\crt\\src;
946 files in my solution
No other plug-ins |
|
|
|
feline
Whole Tomato Software
United Kingdom
18948 Posts |
Posted - Jan 02 2008 : 12:01:13 PM
|
Nothing looks wrong here. Python is unusual, I don't recall seeing anyone else list this as a stable include directory before, but I would not expect this to cause problems.
Are any of the files in your solution also in the stable include directories? I am wondering if you have added files from the Codejock libraries directly to your solution. Doing this can confuse VA.
946 files really is not that large, so the number of files should not be causing a problem.
To try and eliminate the NTFS junction as a factor can you please tell VA to store its symbol database on your C drive, as described in this FAQ entry:
http://docs.wholetomato.com?W332
You just need to edit a single registry key and reload the IDE.
This is going so badly wrong so quickly you should know quite quickly if this has helped or not. |
zen is the art of being at one with the two'ness |
|
|
|
KirillMueller
Ketchup Master
72 Posts |
Posted - Jan 02 2008 : 12:14:27 PM
|
No, the CodeJock files are not listed in my project.
I'll try to store the files in a different location and get back to it. Thanks for the link. |
|
|
|
KirillMueller
Ketchup Master
72 Posts |
Posted - Jan 02 2008 : 12:18:20 PM
|
| While we're at it: I work on different CVS branches of the same code base, sometimes in parallel. |
|
|
|
KirillMueller
Ketchup Master
72 Posts |
Posted - Jan 02 2008 : 12:24:02 PM
|
| At a first glance, things seemed to have improved after I have changed the location of the DB to K:\\VAX (K: being another partition with shadow copies disabled). There are still some symbols that VAX doesn't recognize, but I'll narrow it down first before reporting. |
|
|
|
KirillMueller
Ketchup Master
72 Posts |
|
|
KirillMueller
Ketchup Master
72 Posts |
Posted - Jan 03 2008 : 12:47:24 AM
|
After fixing the issues with the namespaces, I have noticed problems with autosuggest/autocomplete of symbols in the Authorization API (Sddl.h, AclAPI.h, ObjSel.h). These headers are in the "stable includes". I include these rarely used headers in each .cpp module where I need them, and VAX regularly fails to find symbols from these files.
That is, autocomplete won't work for a symbol, but once I have typed it by hand, VAX recognizes it and even Alt+G works. Usually it's about enums with longish names, and things seem to improve after the file that contains the definitions has been opened in the IDE.
Would referencing these files from VAX's StdAfx.h help? Why doesn't VAX simply parse all headers in the stable directories? |
|
|
|
feline
Whole Tomato Software
United Kingdom
18948 Posts |
Posted - Jan 03 2008 : 2:01:02 PM
|
Have a look at:
C:\\Program Files\\Visual Assist X\\Misc\\StdafxVa.h
This file already includes a range of header files, to make sure VA parses them. Adding the three you mention to this file should help with this problem.
Automatically parsing all files in the stable include directories, one answer is speed of loading the project. Some users on large projects already experience problems with how long it takes VA to parse their files, and they don't want VA to do any more parsing than necessary.
Working on two copies of the solution from CVS, this does sound familiar. We had problems where doing this could cause VA's symbol database to become corrupted, but they were supposed to have been fixed a while ago now. For most users they do seem to have been fixed.
Does this seem to trigger the problem? If you work only on one version of the solution for a few hours are you seeing these problems occur? Or do the problems seem triggered by having two IDE's open, one pointing at each version of the solution? |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
Suggestions and Alt+G "have worked better before"
