| T O P I C R E V I E W |
| kinook |
Posted - Jan 04 2007 : 08:58:28 AM
I think this is new to one of the 154x builds: I have a solution with two different Export.cpp/h file pairs (in different projects). In any of these files, instead of opening the corresponding file (which is in the same path), Alt+O shows a popup menu of the other 3 files. This really diminishes the usefulness of Alt+O.
VA_X.dll file version 10.3.1543.0 built 2006.12.19
Licensed to:
VA X: * (1-user license) Support ends 2007.01.11
VA.NET 7.1: * (1-user license)
VAOpsWin.dll version 1.3.4.1
VATE.dll version 1.0.5.5
DevEnv.exe version 7.10.3077.0
msenv.dll version 7.10.3077.0
Font: Andale Mono 13(Pixels)
Comctl32.dll version 5.82.2900.2982
Windows XP 5.1 Build 2600 Service Pack 2
2 processors
Platform: Win32
Stable Includes:
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include\\prerelease;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\SDK\\v1.1\\include;
D:\\Src\\boost_1_33_1;
Library Includes:
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\mfc;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\crt\\src;
Other Includes:
|
| 30 L A T E S T R E P L I E S (Newest First) |
| support |
Posted - Nov 12 2010 : 3:26:39 PM
case=32543 is fixed in build 1836 |
| feline |
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. |
| burbelgruff |
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 |
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. |
| burbelgruff |
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 |
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. |
| burbelgruff |
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 |
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. |
| maxim2000 |
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 |
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. |
| maxim2000 |
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 |
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. |
| burbelgruff |
Posted - Sep 16 2009 : 07:39:23 AM
With our current folder layout, it happens for all duplicate files.
For the following file:
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.h
d:\\depot\\ef\\wrk\\Source\\Core\\Utility\\Utility\\include\\Utility\\Module.h
d:\\depot\\ef\\wrk\\Source\\Core\\ViewModels\\ViewModels\\include\\ViewModels\\Module.h
Where the last file is the one I want it matched up with.
If you open up one of these files in another soulion, Alt+O is unable to find any matching file.
I also have a few cases of the following:
d:\\depot\\ef\\wrk\\Source\\Core\\ViewModels\\ViewModels\\src\\Property.cpp
Where I get the following choices (in the following order)
d:\\depot\\ef\\wrk\\Source\\Core\\Reflection\\Reflection\\include\\Reflection\\Property.h
d:\\depot\\ef\\wrk\\Source\\Core\\ViewModels\\ViewModels\\include\\ViewModels\\Property.h
Again, it is the last file that I want.
Is it possible to make Visual Assist first look in the project to which the current file belongs (if it belongs to one of the projects in the current solution) and try to find a match there first. If it finds one unique match, it selects this. If it finds multiple, or none, it could fallback to the solution (Personally I have no cases where this fallback is required)
|
| maxim2000 |
Posted - Sep 16 2009 : 05:38:20 AM
I don't use Alt-O since its behaviour was changed. I see popup menu that doesn't fit to maximized VS2005 window when I press Alt-O in stdafx.cpp... I hope one day some solution will be found. It would be nice to somehow support an old Alt-O. |
| feline |
Posted - Sep 15 2009 : 5:48:44 PM
Do you have many cases where this problem shows up? I have some existing tests for Alt-O and duplicate files, one of which uses the following two pairs of files:
c:\\src\\ManualVaTests\\tests\\dll_files\\API\\Config\\Documents\\test_scattered_duplicate_alt_o.h
c:\\src\\ManualVaTests\\tests\\dll_files\\Config\\Documents\\test_scattered_duplicate_alt_o.cpp
c:\\src\\ManualVaTests\\tests\\Config\\Documents\\test_scattered_duplicate_alt_o.h
c:\\src\\ManualVaTests\\tests\\Config\\Documents\\test_scattered_duplicate_alt_o.cpp
Alt-O always takes me directly to the matching file. This is close, but not identical, to your situation.
If you make sure none of the instances of the problem file are open in the IDE can you please open VA's Open File dialog, filter it on the file name, and see how many files are listed? Do you get an even or an odd number of files? If you get an odd number of files then VA is not going to be able to pair them up properly, so it will have to show you the file list.
The dialog for pairing files, this is something we are really trying to avoid, since it will involve a fair bit of work for a quite limited benefit, especially when you remember that the pairings have to be saved on a solution by solution basis, etc. |
| burbelgruff |
Posted - Sep 14 2009 : 02:09:18 AM
I have the following directory structure:
Project1\\include\\Project1\\File1.h
Project1\\src\\File1.cpp
Project2\\include\\Project2\\File1.h
Project2\\src\\File2.cpp
When I select Open Corresponding File for one of these files, a list of all the above files are opened.
In a perfect world, I would like Visual Assist to limit the files shown to the files in a project, not all files in the current solution.
If this is unacceptable, an alternative would be that you could do the following:
In Source or header file, press Alt+O:
1. Show list of all files with the same name (as today)
2. Show also a tickbox to the right of each of the files, with an option "Always bind to this file"
3. If you tick off this checkbox, you will never see this menu again when pressing Alt+O for the current file. It will always do the right thing.
4. In Visal Assist Options, you could have a list of all file bindings the user has created.
If this is implemented, it would also be possible to do the following:
When user presses Alt+O and the program is unable to find a corresponding file, you could show the list with only one alternative: "Locate file..." which would allow the user to specify a corresponding file manually.
|
| feline |
Posted - Oct 27 2008 : 2:57:59 PM
Assuming you are seeing the problem with "foo.cpp" can you close all open files then show VA's Open File dialog and filter it on "foo."
How many files are listed?
If there are an odd number of files then VA will not be able to pair them up, so it will show you a menu of choices. |
| cubiq |
Posted - Oct 27 2008 : 11:42:55 AM
So has this been fixed because I still get the same behavoiur under VS 2008 with 10.4.1649.0 |
| support |
Posted - Jul 14 2008 : 2:26:11 PM
case=6044 is fixed in build 1645 |
| feline |
Posted - Aug 27 2007 : 3:30:32 PM
That looks like it may be a factor. Are you using a localised OS?
If you place the project into a directory path with no extended characters does the problem still occur?
This may be related to:
case=6044 |
| WheretIB |
Posted - Aug 25 2007 : 09:16:01 AM
I think this thing will tell something:
 |
| sean |
Posted - Jun 13 2007 : 11:46:13 PM
Sounds like va thinks there are 3 files with the same base name.
What is the full path of the file you are in when this happens?
What are the choices va is giving you in the menu?
|
| WheretIB |
Posted - Jun 13 2007 : 4:58:35 PM
I've installed VA1557 and now, when I press the button "Open Corresponding .h or .cpp" or Alt+O I get a context menu that ask's me to choose between two .h and .cpp files.
There are only two files, and isn't it obvious that if I have .h opened in editor, then I wish to switch to .cpp file?
PS. I can't live like this! :) |
| support |
Posted - Feb 23 2007 : 02:49:40 AM
Case 4562 is fixed in build 1547. |
| support |
Posted - Jan 17 2007 : 3:46:04 PM
Case 4372 is fixed in build 1544. |
| feline |
Posted - Jan 17 2007 : 3:21:10 PM
This file layout is one of the tests we have been using when checking the new alt-o file menu.
simply sorting the files by extension is not going to help, since the one extension will always be at the top of the menu. the current file is not included in the menu, so you cannot jump to that file to help.
We try very hard to avoid adding a load of options to VA, so adding a whole pile of options to control how alt-o scans the solution is very unlikely to happen.
having alt-o progress through the files in order is going to irritate the people who want to move quickly back and forward between just two of the files. |
| Line40 |
Posted - Jan 17 2007 : 12:30:42 PM
Sorry for the vague reference, I meant this one: http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=5681
The file configuration is the same that I mentioned in that thread, see below. I appended the location where the files are stored in the VS 2003 Solution Explorer Window to each line:
D:\\Source\\Sacred2\\Source\\tools\\SUI-Lib\\SUI-Lib\\SUI\\Object.h (Project-Folder: "SUI")
D:\\Source\\Sacred2\\Source\\tools\\SUI-Lib\\SUI-Lib\\SUI\\Object.inl (Project-Folder: "SUI")
D:\\Source\\Sacred2\\Source\\tools\\SUI-Lib\\SUI-Lib\\Object.cpp (Project-Folder: "Source Files") |
| feline |
Posted - Jan 17 2007 : 12:20:53 PM
What thread are you talking about? I am not seeing you reference any other threads in your posts in this thread.
Can you explain the file configuration that you are using, and that you are having this problem with? |
| Line40 |
Posted - Jan 17 2007 : 04:46:09 AM
I tried 1544, but the menu is still displayed. Its the same file configuration that I stated in the thread mentioned. |
| feline |
Posted - Jan 16 2007 : 09:29:42 AM
Try 1544 and see if it fixes your problems with the menu appearing. This should be announced officially in the next few days, unless we come across a serious bug in our internal testing:
http://www.wholetomato.com/downloads/VA_X_Setup1544.exe
I am seeing the same problem with the caret moving when you change files via the alt-o menu.
case=4562 |
