Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 Cannot edit a file which path contains '/'

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
sirius_h 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,
13   L A T E S T    R E P L I E S    (Newest First)
sean 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.
rchen 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.
sirius_h 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.
sean 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.
feline 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.
sirius_h 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 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.
sirius_h 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 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.
sirius_h 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 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
sirius_h 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 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.

© 2021 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000