| T O P I C R E V I E W |
| foxmuldr |
Posted - Oct 10 2023 : 2:33:51 PM
I have dyslexia, and I often align things vertically in my code to assist my ability to read what's there. I had a case today where this code:
s8 local_port[32] = "12345"); // Comment on 12345, operation notes
s8 cloud_port[32] = "23456"); // Comment on 23456, operation notes
s8 log_port [32] = "34567"); // Comment on 34567, operation notes
The log_port token was not recognized with Alt+Shift+F to find all. When I removed the spaces before the [32] it was then recognized and searchable through VA. The spaces are legal in C/C++, so it should probably be supported.
Thank you,
Rick C. Hodgin
|
| 7 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Nov 08 2023 : 07:40:40 AM
VA doesn't try to apply its underlining to a file until the file has been edited, which is an optimisation for speed when just browsing through a large amount of code. But assuming you have parse all files in solution turned On, editing the file should not have any effect on VA having parsed the code.
The closest I can come to an obvious thought is that if not all of the required header files have been parsed already, VA will parse them when you first open the file, and the wait time for this to finish could look like the wait time before you started editing. But in this case the lack of syntax highlighting in the file while VA is parsing should offer a clue. |
| foxmuldr |
Posted - Nov 07 2023 : 10:45:39 AM
This sounds similar to my other bug (https://forums.wholetomato.com/forum/topic.asp?TOPIC_ID=20556), that something wasn't identified until after it was edited. Once edited it recognized it fine, but until then it was getting confused due to some prior incorrect parsing, or Intellisense not parsing it correctly, or whatever else.
--
Rick C. Hodgin
|
| feline |
Posted - Oct 23 2023 : 11:29:31 AM
Strange, honestly not sure what to make of this then. The only other "obvious" theory is that the code was in an incomplete state, so would not compile, and this tripped up our parser. But not a very good theory. Unless we can get this to happen repeatedly I am not sure we will get to the bottom of it. |
| foxmuldr |
Posted - Oct 23 2023 : 09:49:15 AM
Yes. It is checked.
--
Rick C. Hodgin
|
| feline |
Posted - Oct 17 2023 : 05:14:29 AM
It almost sounds like a required file wasn't being parsed, which is rather strange. Assuming you are working with a solution file, do you have:
VA Options -> Performance -> Parse all files when opening a project
turned On or Off? This is the only thing that obviously might matter here. |
| foxmuldr |
Posted - Oct 16 2023 : 11:01:50 AM
When I encountered that issue that day, it worked once it had been parsed following editing.
If I exited the instance of Visual Studio, went back in and re-load the solution, it wouldn't be recognized again until I re-edited.
I can't duplicate it today. It didn't find it one time, but it did find it after I tried one of the other ones and came back to it.
So, I don't know. Mark it not an issue.
--
Rick C. Hodgin
|
| feline |
Posted - Oct 11 2023 : 06:09:18 AM
OK, that should not cause problems. In a simple test, the spaces alone are not a problem. I have the following simple test case, that compiles quite happily in VS2022, with the code in a cpp file:
static void testingSpaceOnArray()
{
char local_port[32] = "12345"; // Comment on 12345, operation notes
char cloud_port[32] = "23456"; // Comment on 23456, operation notes
char log_port [32] = "34567"; // Comment on 34567, operation notes
int nLengthTotal = 0;
nLengthTotal += strlen(local_port);
nLengthTotal += strlen(cloud_port);
nLengthTotal += strlen(log_port);
}
using Alt-Shift-F works for me on both instances of each variable.
Could I get a bigger code sample? The fact that you have closing round brackets at the end of the lines is interesting, and suggests something "odd" is going on here. Perhaps "s8" is a macro that introduces an opening round bracket but not a closing bracket? |
|
|
