| T O P I C R E V I E W |
| endgame |
Posted - Oct 10 2006 : 12:43:18 PM
Hello,
The alt-g improvements in 1538 are excellent, however I'm still experiencing some alt-g issues for files which don't belong to the currently opened workspace.
If I open VC 6.0 without loading any workspace, open foo.h and its corresponding foo.cpp (both residing in the same folder), alt-g doesn't work well: in build 1538, alt-g only works from implementation to declaration and not the other way around.
If reparse the cpp file manually, the alt-g works like charm in both directions.
under the same conditions (both h and cpp open), the goto works perfectly in the 14* versions.
Adding the folder location under the "Custom source files" in the VAX setting, works but is problematic, since I have a complex folder hierarchy. I suggest to add the ability to manually add additional dsw/dsps instead of folders.
Looking forward to any input,
Ofer |
| 23 L A T E S T R E P L I E S (Newest First) |
| support |
Posted - Jul 14 2008 : 2:28:26 PM
case=2943 is fixed in build 1645 |
| endgame |
Posted - Nov 08 2006 : 04:56:13 AM
I agree, VA does far more than alt-g.
Missing alt-g on files outside project is major handicup, though, and a major regression from previous builds.
Deciding between refactoring and alt-g working as it should is a difficult one, and depends on the method of work.
For me, paying the price of loosing the alt-g for files outside the workspace, is too high. This is true, even though I think that the new refactoring capabilities are great. |
| feline |
Posted - Nov 03 2006 : 08:09:03 AM
VA does do a lot of other useful things as well. |
| dingweed |
Posted - Nov 02 2006 : 7:57:46 PM
quote:
Originally posted by sean
Not parsing non-workspace source files for alt+g information was a design decision made in order to prevent symbol noise.
Ah that's what it is, I thought it didn't work becuase I was doing it on Vista. I guess it has nothing to do with Vista. I bought VAX for this reason only, and it's so that I could work on files without a project. VS8 with a project has intellisense as it is, I don't need a plug in for it if I already have a project. I urge you to rethink this decision. We will not be buying more licensees from you guys, thatG??s for sure, if this decision will stand. I wonder how many more people will do the same. |
| feline |
Posted - Oct 31 2006 : 4:09:04 PM
I have upped the priority on this case, hopefully that will help a bit. Unfortunately I do not have any idea when this will be done. |
| endgame |
Posted - Oct 31 2006 : 12:37:05 PM
Yes, I'm seem to be getting the same behaviour here. It's probably the upgrade which caused me to lose the already parsed files.
However, if the source/headers outside my workspace are changed, I need to reparse them manually.
The suggested workaround is quite encumbering. When (if at all) can I expect the 14* behavior to return? |
| feline |
Posted - Oct 30 2006 : 1:25:31 PM
One thing I am not quite clear on, in your original post you say:
>> If reparse the cpp file manually, the alt-g works like charm in both directions.
I have just been testing this with a VC6 project (VA 1540), and using the Qt library as a test set of code. There is a class, QStringList, which is defined in the two files:
C:\\qt\\live\\include\\qstringlist.h
C:\\qt\\live\\src\\tools\\qstringlist.cpp
I have added both directories to the stable include directories list. I have also added the code:
#include <qstringlist.h>
static int getCounter()
{
QStringList listFoo;
listFoo.fromStrList()
return 3;
}
to the project. alt-g on the function "fromStrList" only offers me the header file. Having jumped to the .h file alt-o takes me to the cpp file. Once I have manually reparsed the cpp file alt-g on fromStrList offers me both the .h and cpp files.
Even after closing both QStringList files and restarting VC6 twice alt-g still offers me both locations.
This is quite a bit of fuss, and not ideal, but it does seem to be a working workaround for me. How close is this to what you have done and seen? This seems to be working, and fairly stable for me.
I have found that telling VA to rebuild its symbol database stops alt-g picking up the cpp file, so I have to re-open it and re-parse it manually. This happens when you install a new build of VA, so this could have been a trigger for it no longer working. |
| endgame |
Posted - Oct 30 2006 : 05:34:38 AM
Well,
It seems that even files that appear under additional folders (both "Source files" and "other include files") aren't always (ever?) parsed successfully. alt-g on a symbol belonging to a file stated in the additional folders, isn't found until I open its h manually. Going to the cpp doesn't work regardless of the cpp being open or not. Only a manual reparsing of the cpp makes the implementation available.
In my original post I wrote that goto works when files are added to the additional folders, I guess that either I was wrong, or that we it was lost somewhere on the way.
This means that I currently don't have a workaround, and have to give up on the splendid refactoring stuff, until version 14* behavior is restored somehow. |
| feline |
Posted - Oct 29 2006 : 1:32:18 PM
*ah* I see the problem. In VS2003 or VS2005 the obvious suggestion would be to make a "dummy" project holding these extra files and then exclude it from the build.
For the moment VA's extra folders sound like the best solution. |
| endgame |
Posted - Oct 29 2006 : 12:12:41 PM
The movement from h to cpp is merely a symptom of the real problem, which is: Given a call to a function residing in code I have access to but doesn't belong to the current workspace, allow me to use alt-g to go to the header or the implementation as I see fit (just is the case for code which does belong to the workspace).
Obviously, if the code doesn't belong to the current workspace, I need to open the relevant file manually (unless I put it under additional folders). But once the file was opened, I want to have the ability to navigate the code fluently, regardless of it being part of the current workspace or not. |
| feline |
Posted - Oct 25 2006 : 12:44:37 PM
Out of interest why are you needing to move back and forward between the header and cpp file? I am trying to think of some way to cut down on the number of jumps you have to make.
I am assuming you are not editing the code, since you cannot compile it successfully, since it is not part of the workspace.
Going back to your original post, you said:
>> Adding the folder location under the "Custom source files" in the VAX setting, works but is problematic, since I have a complex folder hierarchy. I suggest to add the ability to manually add additional dsw/dsps instead of folders.
Does your set of directories change much? It is quick and easy to produce a program to scan down the directory tree, listing all of the directory names to a file, which you could then insert into VA's list. |
| endgame |
Posted - Oct 25 2006 : 07:27:30 AM
"Not very elegant" is an understatement :)
These are not two files I'm talking about, but rather hundreds of files.
This is uite a handicap. |
| feline |
Posted - Oct 23 2006 : 1:01:19 PM
I was thinking of the workaround:
IDE 1 has the code you are working on, but does not contain the two files you need to use alt-g on
IDE 2 has the second workspace which contains the two files you need to use alt-g on, so you can read and study the code in this IDE instance, will the full help of alt-g.
Not very elegant, but it should work. |
| endgame |
Posted - Oct 23 2006 : 05:43:22 AM
I don't think its a VA issue, but rather a question of the workspaces I'm working on are rather big 50 projects, with about 4000 files. The mem usage is around 100MB of operating memory + 100MB of virtual memory.
In any case, opening two instances of VC6, one for each workspace, doesn't imrpove the status. The behavior of goto remains the same. |
| feline |
Posted - Oct 18 2006 : 5:48:42 PM
What sort of memory usage are you seeing for each instance of VC6?
There is certainly one user seeing massive memory usage, a bug that we are looking into currently. It is possible you are encountering the same thing. The thread I am thinking of is this one:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=5455 |
| endgame |
Posted - Oct 18 2006 : 12:54:13 PM
The problem is that opening VC6.0 for each workspace takes a lot of memory, coupled with VA memory usage, my computer is almost dead.
I'll give it a try, to see if it fixes the problem, though.
|
| feline |
Posted - Oct 18 2006 : 09:37:02 AM
I have put in a request for VA to respect this registry key
case=2943
Is opening a second instance of VC6 to look at the files in this other project a good work around? I am looking for something that will help in the short term. |
| endgame |
Posted - Oct 18 2006 : 05:03:16 AM
The closest thing in VC6 is to add projects to the dsw and then unload them (right click the project and choose "unload").
This solution if far from perfect, since I'm talking about an external dsw containing about 40 dsps. Additionally, from a quick tst I ran, VAX seems to ignore the unloaded dsps. |
| feline |
Posted - Oct 16 2006 : 11:02:25 AM
In VS2003 / VS2005 you can add a second project to the workspace, and then tell the IDE to ignore it when building. This makes all of the code available to VA, so you can read and study it easily, without having to worry about the IDE building it.
Is it possible to do the same thing in VC6? I have had a look, but the dialog that is used in VS2003 and VS2005 (IDE Build menu -> Configuration Manager...) does not seem to exist in VC6. |
| endgame |
Posted - Oct 15 2006 : 04:57:50 AM
Sorry it took so long..
I'm afraid it didn't work. Only manual reparsing of the cpp file makes it possible to switch from header to implementation for these files. |
| sean |
Posted - Oct 11 2006 : 12:17:21 PM
Not parsing non-workspace source files for alt+g information was a design decision made in order to prevent symbol noise.
You might try the following:
Create a string value named GoToSearchLimitToProject at HKCU\\Software\\Whole Tomato
Set the value to No.
This is undocumented - I don't know if it works as one might intend it to given the name of the value - but it is something to try. You can set this without restarting the IDE.
Let me know if it works!
|
| endgame |
Posted - Oct 11 2006 : 05:00:29 AM
Yes, the files are actually a part of a one or more workspaces I link against.
|
| feline |
Posted - Oct 10 2006 : 4:12:34 PM
Out of interest how are you compiling the cpp files if they are not part of the workspace? Are they part of a separate workspace that is being compiled into a dll which you are then linking against?
i am seeing the same problem here. alt-o still works, which is something when combined with alt-m.
case=2943 |
