| T O P I C R E V I E W |
| hexlog |
Posted - Apr 09 2018 : 04:21:14 AM
---------------------------
Visual Assist
---------------------------
Visual Assist cannot edit dbo.mpm_deviceInfos.sql because the document was opened, likely by an external application, using a method that prevents full access by Visual Studio extensions. Close the document and open it from within Visual Studio.
MSSQL::\120.24.241.209\Iot.Mpm\sa\SqlTable\dbo.mpm_deviceInfos.sql
---------------------------
#30830;#23450;
---------------------------
|
| 17 L A T E S T R E P L I E S (Newest First) |
| sean |
Posted - Jul 13 2018 : 2:45:17 PM
case=116843, case=116561 and case=116840 are addressed in build 2283.
Registry value WarnOnLoadOfPathWithReversedSlashes is now a DWORD. A value of 2 will silently reload files that contain any forward slash. Caret position is restored after reload. |
| sean |
Posted - Jun 01 2018 : 2:20:55 PM
You can disable the prompt entirely via the registry -- but no reload occurs.
Exit all instances of VS, open regedit, goto HKEY_CURRENT_USER\Software\Whole Tomato\Visual Assist X\VANet15 and change WarnOnLoadOfPathWithReversedSlashes from 01 to 00.
We'll update it to support reload without prompt also. case=116843 |
| lex |
Posted - Jun 01 2018 : 2:04:58 PM
Adding a "do not show this message again" option would be great too, if possible. |
| sean |
Posted - Jun 01 2018 : 1:48:50 PM
Thanks for the feedback. We should restore caret position after the reload. case=116840 |
| lex |
Posted - Jun 01 2018 : 1:48:29 PM
quote:
Originally posted by sean
It appears that though the message text isn't completely correct, it is warranted. Some text input operations don't work if you do not allow VA to reload the file when the file has been opened with mixed path delimiters. We don't know what the problem with the VS document is, but some of our calls to VS text operations simply fail when the document is in that state. We found through trial and error that the operation failures occur when the document was opened with any unix-style path delimiters. The problem was originally reported for files opened in VS by the Unreal Editor. It never occurred to us that the problem could be repro'd through the output window.
Thank you for the info. It sounds like a VS bug then. |
| lex |
Posted - Jun 01 2018 : 1:41:14 PM
quote:
Originally posted by feline
This case appears genuine, due to the mixed slashes in the path. Is the problem the message, or the fact that VA is having to re-open the file to be fully active in the file?
The message explains the problem, and since we are working behind the scenes in the IDE, we don't have direct control over how the file is opened. The file has already been opened before we get involved here.
Both. The message interrupts normal work flow. It's easy enough to press enter to let VA reopen the file, but then you lose focus on the error line because the caret is placed at the start of the file. If you don't let VA reopen the file then you can't edit the file normally. You can't type '.', auto complete suggestions doesn't work, indentation on enter doesn't work. It's just a mess.
I've found that compiler errors in headers that are included using a relative path with slashes instead of backslashes gives this "odd" path in the output.
|
| sean |
Posted - Jun 01 2018 : 1:17:32 PM
It appears that though the message text isn't completely correct, it is warranted. Some text input operations don't work if you do not allow VA to reload the file when the file has been opened with mixed path delimiters. We don't know what the problem with the VS document is, but some of our calls to VS text operations simply fail when the document is in that state. We found through trial and error that the operation failures occur when the document was opened with any unix-style path delimiters. The problem was originally reported for files opened in VS by the Unreal Editor. It never occurred to us that the problem could be repro'd through the output window. |
| feline |
Posted - Jun 01 2018 : 06:28:04 AM
This case appears genuine, due to the mixed slashes in the path. Is the problem the message, or the fact that VA is having to re-open the file to be fully active in the file?
The message explains the problem, and since we are working behind the scenes in the IDE, we don't have direct control over how the file is opened. The file has already been opened before we get involved here. |
| lex |
Posted - May 30 2018 : 4:09:25 PM
quote:
Originally posted by feline
When this happens, if you look at VA's definition field, which is normally at the top of the editor window, on the right hand side, what is the full path for this file? I am wondering if there is anything "odd" about this path, perhaps mixed / and \ in the path?
It happened again now, and I think you're on to something.
The compiler output (in this case) points to a file that has both / and \ in its path. Every time I open it by double clicking in the output window I get that error from VA.
It's easily reproduced with a pragma message that prints an odd path of an existing file to the output window. Like this: #pragma message("c:\\test/file.txt(1)") |
| feline |
Posted - May 28 2018 : 08:56:47 AM
When this happens, if you look at VA's definition field, which is normally at the top of the editor window, on the right hand side, what is the full path for this file? I am wondering if there is anything "odd" about this path, perhaps mixed / and \ in the path? |
| lex |
Posted - May 26 2018 : 2:37:13 PM
I get this sometimes after a "Find in Files" search, when a new file is opened as a result of me pressing the shortcut to get to the next entry in the Find Results window. There are only cpp and h files that belongs to the solution in the search result. And it's a CMake solution if that makes any difference. I can't reproduce it on purpose, it just happens "randomly".
VA_X.dll file version 10.9.2270.0 built 2018.04.30
DevEnv.exe version 15.0.27130.2024 Community
msenv.dll version 15.0.27130.2024
Comctl32.dll version 6.10.16299.431
Windows 10 10.0 Build 16299.431
|
| sean |
Posted - May 19 2018 : 07:03:16 AM
wow -- the bug that won't die... case=116561. Sorry, will address in next release. |
| feline |
Posted - May 19 2018 : 06:08:30 AM
Which version of the IDE and version of VA are you using?
If you say Yes, are you seeing the VA Navigation bar at the top of the editor window when you have a .SQL file open?
Using VS2017 and VA 2270 I am not seeing this message when opening a .SQL file from the Server Object Explorer window. But I am just double clicking on a SQL file in this view. Which types / items do I need to select in order to get "View Data" in the right click menu on an item in this view? I don't really know anything about SQL server, so I am working this out as I go along. |
| hexlog |
Posted - May 18 2018 : 11:55:07 PM
---------------------------
Visual Assist cannot edit dbo.scw_deviceCtrls.sql because the document was opened, likely by an external application, using a method that prevents full access by Visual Studio extensions.
ViewDataWindow_MSSQL__\_localdb__MSSQLLocalDB\Iot.Scw\sa\SqlTable\dbo.scw_deviceCtrls.sql
Do you want Visual Assist to reopen the file for you?
---------------------------
Yes(Y) No(N)
---------------------------
-------------------------------------
Can you disable this prompt?
Because he interfered with my normal work.
Step:
Open SQL Server Object Explorer-> View Data
|
| sean |
Posted - May 01 2018 : 4:47:44 PM
case=115635 is fixed in build 2270 |
| sean |
Posted - Apr 09 2018 : 11:21:44 AM
Sorry, looks like a false positive of an unrelated issue. We'll address it in the next release. case=115635 |
| feline |
Posted - Apr 09 2018 : 08:43:09 AM
Unfortunately the message contains the key bit of information here, the IDE it's self is limiting editing of this file, and this isn't something that VA actually has any control over.
Based on the file path, is the SQL file being opened directly from a SQL database? Or is this from a network share? I have not seen this come up outside of Unreal Editor before. |
