| Author |
 Topic  |
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
 Posted - Sep 16 2009 : 10:07:15 AM
|
maxim2000 can you start a new forum thread for your problem please, preferably with a screen shot, since I do not understand what you are talking about.
burbelgruff in your first file list first, are these file names correct? You are listing one .cpp file and three .h files. VA is not going to be able to pair these up, since you cannot correctly pair one .cpp to three header files.
In your second file list the same problem exists, there is no single "matching" file for our simple definition of matching. |
zen is the art of being at one with the two'ness |
 |
|
|
maxim2000
Ketchup Master
68 Posts |
Posted - Sep 17 2009 : 04:34:29 AM
|
feline, I'm not sure about new thread. I dislike new Alt-O popup menu, but afaik it is by design now.
I have the following situation (just like you described above):
C:\\src\\project_1\\Export.cpp
C:\\src\\project_1\\Export.h
C:\\src\\project_2\\Export.cpp
C:\\src\\project_2\\Export.h
...
C:\\src\\project_150\\Export.cpp
C:\\src\\project_150\\Export.h
So, when I press Alt-O I see a huge popup menu with 150 items. That was it.
I can start a new thread with a screen shot if you still want it. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Sep 17 2009 : 12:37:54 PM
|
You should not be getting a menu in this situation, Alt-O should be taking you directly to the matching file. Can you please download and open this simple test project:
http://forum.wholetomato.com/colin/forumimages/cpp_alt_o_duplicates_test.zip
it is a VS2005 format project with 6 pairs of files, called "ChildFrm.cpp" and "ChildFrm.h", with each pair in a different project and directory. It is basically what you have, just smaller. I never see a menu when testing in this project. |
zen is the art of being at one with the two'ness |
|
|
|
maxim2000
Ketchup Master
68 Posts |
Posted - Sep 18 2009 : 10:19:05 AM
|
Alt-O works fine with your test solution.
I was wrong, actually my projects have more complex structure. The tree of project folders is more branchy.
Does Alt-O work without popup menu with linear project structure only (like your test solution), or folder nesting level doesn't matter?
If Alt-O should work with any folder nesting level I'll put out my project (without sources) to a public domain. You can find there pairs of stdafx.h/cpp files, which cause a huge popup menu. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Sep 21 2009 : 11:07:30 AM
|
if VA finds pairs of files then it will always try to pair them up, so you never get the menu. VA does attempt to handle various different directory structures, the cpp and .h file do not have to be in the same directory for VA to pair them up.
It would be very useful to see your project structure, just these stdafx.h / cpp files. There is no need to place it into the public domain, you can simply send me a copy of the project and we will keep it private, only using it for testing purposes.
Please submit the zip file of the project structure 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. |
zen is the art of being at one with the two'ness |
|
|
|
burbelgruff
New Member
8 Posts |
Posted - Sep 22 2009 : 02:47:43 AM
|
quote:
Originally posted by feline
burbelgruff in your first file list first, are these file names correct? You are listing one .cpp file and three .h files. VA is not going to be able to pair these up, since you cannot correctly pair one .cpp to three header files.
In your second file list the same problem exists, there is no single "matching" file for our simple definition of matching.
Hmm. Copy paste isn't as easy as it seems :(
The first set of files is supposed to be:
Project1\\include\\Project1\\File1.h
Project1\\src\\File1.cpp
Project2\\include\\Project2\\File1.h
Project2\\src\\File1.cpp
Sorry for the typo.
The second list of files is supposed to be:
d:\\depot\\ef\\wrk\\Source\\Core\\ViewModels\\ViewModels\\src\\Module.cpp
I get the following choices (in the following order)
d:\\depot\\ef\\wrk\\Source\\Core\\Utility\\Utility\\src\\Module.cpp
d:\\depot\\ef\\wrk\\Source\\Core\\Utility\\Utility\\include\\Utility\\Module.h
d:\\depot\\ef\\wrk\\Source\\Core\\ViewModels\\ViewModels\\include\\ViewModels\\Module.h
Sorry again for the typo.
Yes, the files are always matched.
Even if I have the following file set:
d:\\depot\\ef\\wrk\\Source\\Core\\ViewModels\\ViewModels\\src\\Module.cpp
d:\\depot\\ef\\wrk\\Source\\Core\\Utility\\Utility\\include\\Utility\\Module.h
d:\\depot\\ef\\wrk\\Source\\Core\\ViewModels\\ViewModels\\include\\ViewModels\\Module.h
I would expect Visual Assist to first look in the current project and terminate the search if it found a match. Listing a file with the same name in a different project is simply wrong. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Sep 22 2009 : 12:49:47 PM
|
burbelgruff I am seeing the same problem here, I have re-opened:
case=16697
for this. I am not sure about limiting Alt-O to the current project. It is a simple and tempting idea, but it won't help when the duplicate file names are all in the same project. Also there is the situation where VA is working without a project, or a file has been added to more than one project at the same time.
I have put a note on the case about this though, to see what our developers make of it. |
zen is the art of being at one with the two'ness |
|
|
|
burbelgruff
New Member
8 Posts |
Posted - Oct 14 2009 : 07:26:33 AM
|
I just thought of a way that may solve this by parsing files for include statements:
If you have the following setup:
Project1\\include\\Project1\\File1.h
Project1\\src\\File1.cpp
Project2\\include\\Project2\\File1.h
Project2\\src\\File1.cpp
Project1\\src\\File1.cpp looks like this:
#include <Project1\\File1.h>
...
Project2\\src\\File2.cpp looks like this:
...
#include <Project2\\File1.h>
...
It would be possible, when pressing Alt+G to parse all include statements in all corresponding files and try to deduce what file is meant.
If I opened <Project1\\include\\Project1\\File1.h>
and pressed Alt+G,
Searching all include statements in <Project1\\src\\File1.cpp> , you would find <Project1\\File1.h> which matches partially the path name of the original file.
Searching all include statements in <Project2\\src\\File1.cpp> , you would find <Project2\\File1.h> which does not match the path name of the original file.
<Project2\\include\\Project2\\File1.h> does not reference any File1.h
We now have three candidates, but only one of them includes <Project1\\include\\Project1\\File1.h> (Or at least, it is likely that it does)
This file is then the best match, and is chosen. If no best match is found, or more than one best matches are found, show all.
In the opposite case:
If I opened <Project1\\src\\File1.cpp>
and pressed Alt+G,
This file explicitly states that it includes <Project1\\File1.h>
If we can find only one file that matches this pattern, we open this file. If zero or more than one files are found to match this pattern, show a list of all files. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Oct 14 2009 : 09:48:45 AM
|
When you write Alt-G do you really mean Alt-G or do you mean Alt-O?
I am not sure I really understand the method you are describing, which bothers me from a support point of view. It will be hard to explain why VA is doing what it is doing if / when this method goes wrong. |
zen is the art of being at one with the two'ness |
|
|
|
burbelgruff
New Member
8 Posts |
Posted - Oct 15 2009 : 12:26:54 PM
|
Hmm. I seem to be unable to post a reply without typos :( Yes, I meant Alt-O.
I'll give one more shot at trying to explain what I mean by posting an example:
Assume I have four files:
Project1/include/Project1/File1.h
#pragma once
#include <string>
std::string Foo();
Project1/src/File1.cpp
#include <Project1/File1.h>
void Foo()
{
return "Foo";
}
Project2/include/Project2/File1.h
#pragma once
#include <string>
std::string Bar();
Project2/src/File1.cpp
#include <Project2/File1.h>
void Bar()
{
return "Bar";
}
When compiling Project2/src/File1.cpp, the compiler looks in the current include paths and tries to find the file <Project2/File1.h> in one of the include paths. Why does it do this?
Because we have explicitly written
#include <Project2/File1.h> in the cpp file. The compiler will never try to include <Project1/File1.h> in stead, just because the file name happens to be the same.
What I am suggesting is for Visual Assist to implement this logic. Of course, VA needs to be more liberal when it comes to what it considers as the set of include paths.
This would help resolve ambiguities when going from a .cpp file to its corresponding header file.
When going from .h to .cpp, VA could reverse the logic. Locate all files with the same name that has an include reference to this header file. If only one is found, open this file. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Oct 17 2009 : 09:27:48 AM
|
We are considering changing Alt-O so that it looks for a file only in the current project, if there are several files with the same name showing up:
case=32543
hopefully this will help. |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Nov 12 2010 : 3:26:39 PM
|
| case=32543 is fixed in build 1836 |
Whole Tomato Software, Inc. |
|
|
|
Topic |
|
Open Corresponding file gives too many choices
