| Author |
 Topic  |
|
|
sirius_h
New Member
France
6 Posts |
 Posted - Feb 16 2018 : 04:25:32 AM
|
Hello,
We are facing a problem regarding Visual Assist with some file paths.
System information
VA_X.dll file version 10.9.2248.0 built 2017.12.16
DevEnv.exe version 8.0.50727.867 Professional (Visual Studio 2005)
Windows 7 6.1 Build 7601 Service Pack 1
4 processors (x86-64, WOW64)
Language info: 1252, 0x40c
Problem description
We've got a multi-platform (Linux/Windows) tool that verifies our project source code compliance and outputs the file path and line number when an error is found.
The output is done in the Output window of Visual Studio. An error line looks like that:
D:\projects\my_project/modules/foo_module/bar.cpp(42) : error here
The first part of the path, the current folder path, uses '\' characters for separating path pieces. The second part, the sub-path appended by the tool, uses '/'.
This line is compatible with Visual Studio, so a double-click on that line will open the referenced file and move the cursor at the expected line (42 in the example).
However, when the file is open, it is not possible to write a ',' or '.' (coma or dot) character. Syntax highlighting is working though. Without Visual Assist, the filed can be edited normally.
Steps to reproduce
1. Open any C++ solution in Visual Studio
2. Create a random folder in the C++ solution folder, containing an empty C++ file
3. Create a BAT file named "va-bug.bat" in the solution folder, containing this line (replace with your specific solution folder path):
@echo C:\your_solution_folder\random_folder/random_file.cpp(32) : some error
4. In Visual Studio, select Tools > External Tools...
5. Click Add and fill the form:
- Title: va-bug
- Command: $(SolutionDir)\va-bug.bat
- Check "Use Output window"
6. Click OK
7. Run the tool with Tools -> va-bug
8. Double-click on the file path displayed in the Output window
9. The file opens. Some keys work, some others like the coma or the dot do not work
I think it's a matter of handling '/' the same way than '\'. If the '/'s in the file path are replaced with '\'s, Visual Assist will not prevent file editing.
Best Regards,
|
|
|
feline
Whole Tomato Software
United Kingdom
18746 Posts |
Posted - Feb 16 2018 : 06:16:01 AM
|
| Thank you for the very clear instructions. I am seeing the same problem here, but only when opening an empty .h file. Are you seeing this problem with a file with actual text, actual code inside of it, or only with an empty file? It's still a bug, but if it only happens with empty files, which in theory should not generate any errors, its a much less serious bug. |
zen is the art of being at one with the two'ness |
 |
|
|
sirius_h
New Member
France
6 Posts |
Posted - Feb 16 2018 : 07:06:59 AM
|
quote:
Originally posted by feline
Thank you for the very clear instructions. I am seeing the same problem here, but only when opening an empty .h file. Are you seeing this problem with a file with actual text, actual code inside of it, or only with an empty file? It's still a bug, but if it only happens with empty files, which in theory should not generate any errors, its a much less serious bug.
Thank you for your quick answer.
Yes, we also see the problem with non-empty files. Actually the problem was detected while attempting to fix defects found in our code base.
It just happened that I suggested a zero-sized C++ file because I wanted a minimal test-case.
Maybe if you add some lines of code and use a real line number in the BAT file you will be able to reproduce the issue more often? |
|
|
|
feline
Whole Tomato Software
United Kingdom
18746 Posts |
Posted - Feb 16 2018 : 08:39:48 AM
|
After some more testing, for me this happens with any path that contains either mixed slashes, or all Unix slashes. However, it only happens for me if the opened code file is not part of the solution. I suspect this is happening because if the file is part of the solution, it is already known with a path that VA is happy with.
Some of my test files were part of the solution, but some weren't, which is actually the difference I was testing, instead of empty or not empty.
So for now an initial work around is to add these code files to your solution, assuming they are actually part of your solution.
I have put in a bug report for this:
case=114528 |
zen is the art of being at one with the two'ness |
|
|
|
sirius_h
New Member
France
6 Posts |
Posted - Feb 16 2018 : 09:04:29 AM
|
quote:
Originally posted by feline
After some more testing, for me this happens with any path that contains either mixed slashes, or all Unix slashes. However, it only happens for me if the opened code file is not part of the solution. I suspect this is happening because if the file is part of the solution, it is already known with a path that VA is happy with.
Some of my test files were part of the solution, but some weren't, which is actually the difference I was testing, instead of empty or not empty.
So for now an initial work around is to add these code files to your solution, assuming they are actually part of your solution.
I have put in a bug report for this:
case=114528
Oh nice, you've been refining the test case. You are right, now I understand why we did not see the problem earlier: our code base contains some Linux specific files that we edit from Visual Studio but are not declared in any Visual Studio file (sln or vcproj). These Linux specific files are actually referenced in Makefiles that are not seen by Visual Studio. I found the bug this morning because some defects were detected by our tool in a Linux specific file.
Because most of our code base is made of shared source code between Linux and Windows (thus, referenced by vcproj files and seen by Visual Studio), it won't be a that much of a burden to fix Linux specific defects with another text editor while you fix Visual Assist.
Thank you for your time.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18746 Posts |
Posted - Feb 16 2018 : 10:17:53 AM
|
| One option would be to add a "Linux files" project to your solution and exclude it from the build process. Then add these Linux only files to this project, which means that when working under Windows you can use a single editor for all of your code. This should work around the problem with VA and editing the files, and hopefully slightly simplify things for you, so long as adding this extra project is a reasonable option. |
zen is the art of being at one with the two'ness |
|
|
|
sirius_h
New Member
France
6 Posts |
Posted - Feb 16 2018 : 10:52:21 AM
|
quote:
Originally posted by feline
One option would be to add a "Linux files" project to your solution and exclude it from the build process. Then add these Linux only files to this project, which means that when working under Windows you can use a single editor for all of your code. This should work around the problem with VA and editing the files, and hopefully slightly simplify things for you, so long as adding this extra project is a reasonable option.
That could work. Thank you for your suggestion. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18746 Posts |
Posted - Feb 16 2018 : 11:26:21 AM
|
I have just tried this test on an internal build of VA, which has some changes to handle paths with mixed slashes. When opening the file from the output window, I get a message box informing me that the way the file was opened blocks full access from Visual Studio extensions. So not something we have full control over.
So if you find VA helpful when editing, a "dummy" project, just so the files are part of the solution, seems like a good work around. |
zen is the art of being at one with the two'ness |
|
|
|
sirius_h
New Member
France
6 Posts |
Posted - Feb 19 2018 : 05:53:10 AM
|
quote:
Originally posted by feline
I have just tried this test on an internal build of VA, which has some changes to handle paths with mixed slashes. When opening the file from the output window, I get a message box informing me that the way the file was opened blocks full access from Visual Studio extensions. So not something we have full control over.
So if you find VA helpful when editing, a "dummy" project, just so the files are part of the solution, seems like a good work around.
Well, if Visual Studio does not let you fix the problem, I guess we'll have to live with the workaround. Thank you for looking at the issue. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18746 Posts |
Posted - Feb 20 2018 : 08:15:28 AM
|
| We are still looking into the problem, but if adding the files to the solution is a reasonable work around, this is a fix that you can apply now. Apologies for this. |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - May 01 2018 : 5:05:27 PM
|
| For case=114528, starting in build 2270, VA offers to close and re-open the file when it encounters this problem. |
|
|
|
sirius_h
New Member
France
6 Posts |
Posted - May 07 2018 : 03:06:00 AM
|
quote:
Originally posted by sean
For case=114528, starting in build 2270, VA offers to close and re-open the file when it encounters this problem.
Nice, thank you for your efforts. |
|
|
|
rchen
New Member
7 Posts |
Posted - Nov 15 2019 : 1:30:59 PM
|
Could we add an option to just disable the prompt?
My VS output prints file pathes like this one "..\Code\Blah\Bleh\Misc\SettingManagers.cpp" and it triggers the prompt all the time, it gets in the way and is very annoying. |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Nov 15 2019 : 2:56:59 PM
|
Yes, there are two other behaviors that can be set:
https://docs.wholetomato.com/default.asp?W826
Though those warnings should not be raised with the example paths you listed. |
Edited by - sean on Nov 15 2019 2:59:19 PM |
|
|
| |
Topic |
|
Cannot edit a file which path contains '/'
