Author |
Topic |
|
Line40
New Member
Germany
6 Posts |
Posted - Nov 29 2006 : 08:45:45 AM
|
Hi
I'm having several problems with the, otherwise very useful, Alt-O feature.
First, if I have a file layout like this, with a similar layout in the IDE (The folders in the IDE are called the same and have the corresponding files stored in them) Include/File.h Include/File.inl Implementation/File.cpp Using Alt-O from .h and .inl only switches between those two, the .cpp-file is never opened. However when I'm using Alt-O from the .cpp-file it correctly switches to the .h file. This is pretty annoying since usually .cpp and .h files change much more frequently than .inl files.
The Second problem is this: I have some files called Object.h, Object.cpp in my project, and I'm using an SDK that also has a Object.h file in it. Now when using Alt-O from my Object.cpp file, it opens the Object.h file in the SDK instead of the one in my project. The SDK files are not part of the project/solution, they are just referenced in the Additional Include/Additional Library settings of the project. Shouldn't Alt-O only open files that are part of the project?
Is there a way to either work around this problems or, -even better- ,have them fixed?
Cheers
Line40 |
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Nov 29 2006 : 7:16:22 PM
|
The first problem and the second problem overlap. Alt-o is not restricted to files in the solution, since this would seriously limit its usefulness.
The second problem shows that alt-o can pick up files in different locations, which is confusing since alt-o is not picking up the files in problem 1.
Can you post the complete path's of the three files in the first problem? You should not be having this problem.
For problem two, is it an option to rename the projects files, so you no longer overlap with the SDK files? |
zen is the art of being at one with the two'ness |
|
|
Line40
New Member
Germany
6 Posts |
Posted - Nov 30 2006 : 04:23:12 AM
|
If you don't want to default to restricting Alt-O file searching to files in the solution, why not make it a switch in the VAX options? I know from my experience, and from that of my colleagues at work, that we only work on files in the solution. Also, since we're using a lot of third party SDK's (we're talking about as much as 20 here!) there is a very high probability of file name clashes, so renaming files would not be an option.
As for the requested paths: First problem D:\\Source\\Sacred2\\Source\\tools\\SUI-Lib\\SUI-Lib\\SUI\\Object.h D:\\Source\\Sacred2\\Source\\tools\\SUI-Lib\\SUI-Lib\\SUI\\Object.inl D:\\Source\\Sacred2\\Source\\tools\\SUI-Lib\\SUI-Lib\\Object.cpp Second problem Same paths as in first problem, plus D:\\Source\\Sacred2\\Source\\sdk\\libsigc++-2.0.17\\include\\sigc++\\object.h
Regarding your remark that the SDK object.h is not picked when using Alt-O on the .h and .inl file, I assume that the search order first searches for matching files in the current directory, and from there goes to the other locations, so since it always finds a matching file, it doesn't look further. On the other hand the .cpp file is in a separate directory, so since no matching file is found there, VAX goes on to search in different directories, finding the SDK object.h file before the one in the project. |
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Nov 30 2006 : 4:16:11 PM
|
I can reproduce both problems here quite easily, which is a surprise. I have seen various "odd" directory structures and mixing of files, but normally they do not cause problems like this. The first problem is:
case=3876
The second problem is:
case=3877 |
zen is the art of being at one with the two'ness |
|
|
Line40
New Member
Germany
6 Posts |
Posted - Dec 07 2006 : 03:25:41 AM
|
Thanks for looking into the matter! Is there some other way to track the status of the issues other than monitoring the website for new releases? Since our maintenance runs out in January, I would also like to know if its possible to get them fixed by then or if there will be an extension of the maintenance period until the issues are resolved?
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Dec 07 2006 : 10:56:17 AM
|
Subscribe to this topic and you'll get an email when we post a "case is fixed" notice in it.
We don't extend maintenance for free if a particular bug isn't yet fixed. When you pay for maintenance, you get all the stuff we fix, and you hope your critical bugs get fixed sooner than later. Obviously, bugs have priorities and we try our best to serve our customers well. If you're patience runs thin, post a gentle plea in this thread and we'll bump priority.
Your two bugs have already been fixed internally. You'll see fixes in our next build. |
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Dec 19 2006 : 8:51:22 PM
|
case=3876 and case=3877 are addressed in build 1543 |
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Jan 17 2007 : 3:46:45 PM
|
Fix for case 3876 is improved in build 1544. |
|
|
|
Topic |
|