| T O P I C R E V I E W |
| jmihalicza |
Posted - Dec 03 2007 : 5:32:27 PM
I try to make my explanation more comprehensible by describing my concrete case.
I am developing a sudoku solver and I have a Sud::Grid class which is the abstraction for the table itself, and I have a SudGui::Grid class representing the GUI part. These classes are defined in different projects and namespaces in the same solution, but their filenames are the same, grid.h and grid.cpp accordingly.
I have already met similar situations in layered architectures when a library was based on another one and typically had name clashes like window.h, string.h.
It is a good feature that VA offers the selection of the jump target, instead of jumping to the wrong one, but the pairing in fact is static. After a while it is quite annoying selecting the same choice.
I would only like to help VA to find the pair from the listbox, but once I specified it, I expect VA to memorize my selection.
I can for example imagine the Shift modifier for this function (Shift + click or Shift + Enter), and the same could be used to remove the memorized pair (Alt + Shift + G). |
| 8 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Dec 07 2007 : 3:33:03 PM
*ah* that helps to explain why we were seeing different things. We have been improving how alt-o handles duplicate and scattered pairs of files in recent builds. |
| jmihalicza |
Posted - Dec 07 2007 : 08:33:47 AM
Feline, thanks for your test, now I installed the latest version (1619) and it works fine. I have been using version 1561.
Yes, the problem occured even before adding wxwidgets to the solution.
|
| feline |
Posted - Dec 06 2007 : 2:24:03 PM
I wonder if that "spare" header file in WXWidgets is causing the problem. As an initial test I have created the 4 files:
C:\\work\\suli\\sudoku\\sud\\grid.h
C:\\work\\suli\\sudoku\\sud\\grid.cpp
C:\\work\\suli\\sudoku\\sudgui\\grid.h
C:\\work\\suli\\sudoku\\sudgui\\grid.cpp
and added them to a VS2005 solution using VA 1619. Alt-o always goes directly to the matching file, I have tried in in all of these files.
I have just downloaded WX Widgets 2.8.7, but after installing it I can only find the files:
C:\\wxWidgets-2.8.7\\include\\wx\\grid.h
C:\\wxWidgets-2.8.7\\include\\wx\\generic\\grid.h
there is no sign of a grid.cpp
Were you seeing this Alt-o problem before you added WXWidgets to the project? |
| jmihalicza |
Posted - Dec 06 2007 : 11:16:55 AM
I have the following files:
d:\\work\\suli\\sudoku\\sud\\grid.h
d:\\work\\suli\\sudoku\\sud\\grid.cpp
d:\\work\\suli\\sudoku\\sudgui\\grid.h
d:\\work\\suli\\sudoku\\sudgui\\grid.cpp
C:\\wxWidgets-2.8.6\\include\\wx\\grid.h
C:\\wxWidgets-2.8.6\\include\\wx\\generic\\grid.h
C:\\wxWidgets-2.8.6\\include\\wx\\generic\\grid.cpp
Initially the WxWidgets library was not added to the solution, but ALT+O is still uncertain after adding it.
All of the above files are now part of the solution and there are no other grid.{h,c}* files.
VA keeps offering all the other 6 files whenever I press ALT+O in any of them. Unfortunately the first entry is usually not what I want, so a simple Enter cannot simplify the flow. |
| feline |
Posted - Dec 06 2007 : 09:13:40 AM
Alt-o should handle this correctly.
If you look in solution explorer are all of these files listed? If only 2 or 3 of these 4 files are listed in solution explorer then VA tends to get confused, and alt-o will not know for certain which file to jump to. Adding the missing files should fix the problem. |
| jmihalicza |
Posted - Dec 06 2007 : 04:20:35 AM
Yes, Sud and SudGui are the namespace names.
I have just noticed that I successfully confused everyone, in fact I would have liked to write about ALT+O instead of ALT+G everywhere. I am sorry about that.
So please reinterpret the post according to that, this is why I was talking about pairs.
I try to edit the original post. |
| feline |
Posted - Dec 05 2007 : 4:23:55 PM
My initial reaction is that this sounds like a parser bug, or limitation. jmihalicza are "Sud" and "SudGui" the namespace names?
In the code does VA know which class you are using, and which namespace it belongs to? Or does VA not know which class you are using, so it is offering all classes with the same name that it knows about?
Telling VA to always "use this class" makes sense, but it might be easier / better to use some form of "hack" in the code its self, so that VA understands which class you are using. This bypasses possible problems with VA having to remember and then forget things.
At a basic level I am thinking of adding:
#ifdef VA_VALID_CODE_BUT_DOES_NOT_COMPILE
using namespace Sud;
#endif // VA_VALID_CODE_BUT_DOES_NOT_COMPILE
to the top of the cpp file, so that VA's parser gets the extra clue it needs, without actually changing the code its self, since the pre-processor will strip this out. |
| sl@sh |
Posted - Dec 04 2007 : 10:19:15 AM
I have similar problems for my solution which has 3D Surface objects and graphical represantations of the same with various instances of 'Point' and 'Vector' classes in different contexts and libraries. Makes a lot sense to me for VA to remember the appropriate pairings once chosen.
The only problem I can imagine is with headers that don't have names corresponding to their implementation file names, resulting in a set of files that do not have a single obvious pairing: in such a case it isn't clear whether or not a pairing actually makes sense - VA migth as well assume the header is a standalone declaration of an abstract class! |
