| Author |
 Topic  |
|
kinook
Senior Member
USA
37 Posts |
 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:
|
Automate your software builds with Visual Build Pro
http://www.visualbuild.com/ |
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jan 04 2007 : 11:26:26 AM
|
This is new in (from memory) 1543. It happens when VA does not know which file to choose when using alt-o.
I am assuming that both projects are part of the same solution. If you close all open files and then look in OFIW do you see all 4 of these files?
Can you post the full paths for the 4 files? I think you are saying you have:
C:\\src\\project_one\\Export.cpp
C:\\src\\project_one\\Export.h
C:\\src\\project_two\\Export.cpp
C:\\src\\project_two\\Export.h
but it is good to check these things.
Did alt-o work as expected in the previous build of VA you were using? |
zen is the art of being at one with the two'ness |
 |
|
|
kinook
Senior Member
USA
37 Posts |
Posted - Jan 04 2007 : 3:55:29 PM
|
Yes, all files are part of the solution (in two different projects), and all the files show up (with correct path) in OFIW.
The paths are:
Solution:
C:\\Files\\Kinook\\Source\\UltraRecall\
One pair is at
C:\\Files\\Kinook\\Source\\UltraRecall\\Data\\PimxDB\
and the other at
C:\\Files\\Kinook\\Source\\UltraRecall\\GUI\\UltraRecall\
This did work properly in previous versions, but I'm not sure exactly when it stopped (probably 1543 or 1541). |
Automate your software builds with Visual Build Pro
http://www.visualbuild.com/ |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jan 04 2007 : 6:02:37 PM
|
I am seeing the same effect here. This is new in 1543. I have put in a bug report for this, but personally I am not sure of the best solution. This menu, listing extra files, was added to address a large number of requests, and several bugs, so simply removing it is not a good plan.
Sorting the menu so that the file (or files) in the current project are always at the top is one solution.
case=4372 |
zen is the art of being at one with the two'ness |
|
|
|
kinook
Senior Member
USA
37 Posts |
Posted - Jan 04 2007 : 6:19:05 PM
|
I think there should at least be an option to always open the corresponding file (if there is one in the same path) without any additional prompting. The popup menu choice is annoying because it is one more step and it comes up at the mouse cursor position, which may not be anywhere (often not even the same monitor) near the text editor caret.
Another possibility would be two different commands, one for open corresponding, another for open similar. |
Automate your software builds with Visual Build Pro
http://www.visualbuild.com/ |
Edited by - kinook on Jan 04 2007 6:19:40 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jan 05 2007 : 08:02:37 AM
|
It is very easy to agree with you, but the problem is to define the "corresponding" file. One very common request is for alt-o to respect the group of files foo.cpp, foo.h, foo.inl
So if they are all in the same directory then what is the corresponding file?
Also remember that alt-o needs to work when the cpp and .h files are in different directories. It is quite common for people to structure their projects so that these files are one or two directories apart, sometimes more. |
zen is the art of being at one with the two'ness |
|
|
|
kinook
Senior Member
USA
37 Posts |
Posted - Jan 05 2007 : 08:14:10 AM
|
| Two commands would probably work best then. Alt+O would truly be 'open corresponding', directly opening the related file without prompting even if in a different path (perhaps alternating between inl/h/cpp if all 3 exist). 'Open similar' would display a popup menu of all similarly named files. And it would be nice if the popup menu were displayed near the editor caret rather than the mouse cursor if initiated via the keyboard. |
Automate your software builds with Visual Build Pro
http://www.visualbuild.com/ |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jan 05 2007 : 08:38:31 AM
|
1543 fixed a couple of problems with alt-o that were discussed in this thread:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=5681
I understand where you are coming from. From your perspective something that worked perfectly is now "broken". Unfortunately there were quite a lot of cases where alt-o did not work correctly, so the concept of two separate events, one for "corresponding" files and one for "similar" files does not work so well, simply because we cannot easily draw a line between these two concepts.
I have asked for case=4372 to be looked at quite soon, since we have "broken" existing behaviour. But finding a good fix, that does not break something else is sometimes a little tricky.
The position of the menu, this has been discussed before with regards to the alt-g menu. For the alt-g menu it makes more sense since this can be triggered either via the mouse or the keyboard. with alt-o it is a little less obvious, since this is, almost by definition, a keyboard operation. |
zen is the art of being at one with the two'ness |
|
|
|
daves
New Member
8 Posts |
Posted - Jan 09 2007 : 11:54:48 AM
|
Please bump this priority. For my way of working, Alt-O is the single most-used feature of Visual Assist, and having the menu of choices pop up defeats its usefullness IMHO.
This is a showstopper for me - my Alt-O habit is too strong - I have reverted back to build 1541 until this can be fixed.
My kneejerk suggestion would be to provide a new function that will always open the corresponding .h / .cpp (ignore .inl if you must) that is a member of the same project. That should do what the old Alt-O implementation did in most cases.
Thanks
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jan 09 2007 : 4:04:29 PM
|
| daves where are these duplicate files coming from for you? is it the same file layout, with the pairs in different projects, or something else? |
zen is the art of being at one with the two'ness |
|
|
|
daves
New Member
8 Posts |
Posted - Jan 09 2007 : 5:29:24 PM
|
Yes, I think my situation is the same one described in other posts.
I have many MFC projects in the same solution and they all have MainFrm.h/.cpp file pairs in them. When I am in the MainFrm.h in project P1 and hit Alt-O, the menu shows all MainFrm.cpp files in all the projects, when I clearly want the MainFrm.cpp that is in the P1 project.
Someone from WholeTomato has already gotten back to me via email about this, and I think they will have a fix for this in the next build. I am very impressed with the level of support I've gotten thus far on this issue!
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jan 09 2007 : 6:07:12 PM
|
We do try  |
zen is the art of being at one with the two'ness |
|
|
|
Line40
New Member
Germany
6 Posts |
Posted - Jan 16 2007 : 04:41:58 AM
|
Hi, everyone
Since I am one of the guys that caused the new Alt-O behaviour -I started the thread mentioned- and I have trouble adjusting to the new behaviour too, I thought I give my thoughts on the subject. First, I have to agree with the previous posters, displaying a menu as default is defeating the purpose of Alt-O for me too, since I now have to read the filenames and select the appropriate one, which sort of breaks the coding flow (don't know how to describe this more directly).
Now my suggestion would be to sort the files by filetype. Then the Alt-O key would always select the next file in the sorted list, or revert to the beginning once all files have been iterated through. I think this would be intuitive and consistent, since I would know that, if I'm currently at the .inl file, pressing Alt-O once would take me to the .cpp file, pressing it twice would take me to the .h file etc.
Furthermore, to further increase the usefulness, I would like to suggest adding some options to the Alt-O feature: I would like to select if I want to search files
- in the whole solution (grouping them first by project and then sorting each group by filetype)
- in the project the current file is in (sorting by filetype)
- and both of those including header files referenced in the Project Settings' "Additional Include Directories" (grouping them by external, then project and then sorting each group by filetype)
This way I could configure the Alt-O behaviour so that files by the same name in different projects are either not iterated at all or iterated in a predefined manner that allows "dumb" pressing of Alt-O X times to get to file Y.
I can explain the grouping in greater detail if needed, I think this posting is long enough already 
One more thing though, a bug actually. When selecting the file from the menu displayed on Alt-O, the write-cursor is always at the beginning of the file, regardless if I was editing the file somewhere in the middle. This is very annoying since I now have to either massively work with Bookmarks to jump to my edit locations or not use Alt-O at all. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
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 |
zen is the art of being at one with the two'ness |
|
|
|
Line40
New Member
Germany
6 Posts |
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
Whole Tomato Software
United Kingdom
19021 Posts |
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? |
zen is the art of being at one with the two'ness |
|
|
|
Line40
New Member
Germany
6 Posts |
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
Whole Tomato Software
United Kingdom
19021 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Jan 17 2007 : 3:46:04 PM
|
| Case 4372 is fixed in build 1544. |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Feb 23 2007 : 02:49:40 AM
|
| Case 4562 is fixed in build 1547. |
|
|
|
WheretIB
Junior Member
20 Posts |
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! :) |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
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
Junior Member
20 Posts |
Posted - Aug 25 2007 : 09:16:01 AM
|
I think this thing will tell something:
 |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
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 |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Jul 14 2008 : 2:26:11 PM
|
| case=6044 is fixed in build 1645 |
Whole Tomato Software, Inc. |
|
|
|
cubiq
New Member
6 Posts |
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 |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
burbelgruff
New Member
8 Posts |
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
Whole Tomato Software
United Kingdom
19021 Posts |
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. |
zen is the art of being at one with the two'ness |
|
|
|
maxim2000
Ketchup Master
68 Posts |
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. |
|
|
|
burbelgruff
New Member
8 Posts |
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)
|
|
|
|
Topic |
|
Open Corresponding file gives too many choices
