| T O P I C R E V I E W |
| kimbo |
Posted - Oct 31 2024 : 3:37:38 PM
Hello,
since some weeks I have the problem, that most of my "using" types aren't recognized by VAX any more. But "typedef" works:
Large codebase, in test projects it's fine. Is this a known issue?
VA_X64.dll file version 10.9.2537.0 built 2024.10.27
DevEnv.exe version 17.11.35303.130 Professional
Intellisense is disabled
|
| 9 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Nov 11 2024 : 08:45:43 AM
Strange, I have been using the asm method for quite a while now. I only use it occasionally, it is true, but it is working as expected for me here.
Still, I am glad you have a working solution for this problem!
Obviously, do try and remember that when you install a new version of this library you will probably have to re-apply this fix.
Hopefully you won't have any more odd problems like this. |
| kimbo |
Posted - Nov 11 2024 : 04:27:16 AM
Nope, the _asm doesn't help. I had to remove it from the solution (which is fine) |
| feline |
Posted - Nov 06 2024 : 07:56:35 AM
VA is designed to parse "inactive" code, and to be active there, so this code is being parsed. This is because, when working under Windows, for example, you will still want VA to help you with a block of code inside
#ifdef LINUX
// much code here...
#endif
But, yes, occasionally this does cause problems. As for ignoring code for certain symbols, you start running into "fun" edge cases, like the BOOL type. Plus people who use macros to replace the "class" keyword... the "fun" things people do with macros.
Here though, assuming you are able to edit this library file, can you please wrap this #define like this:
#if 1 == 0
_asm {
#endif
#if defined(using)
#define using EMIT WARNING C4005
#error The C++ Standard Library forbids macroizing the keyword "using".
#if 1 == 0
}
#endif
Obviously the pre-processor will strip these two blocks from the header file when you compile, but VA will see them, and then ignore anything between them, so hiding this #define from VA.
You will probably want to trigger a VA symbol database rebuild at this point, to make sure this macro is cleared from VA's symbol database:
VA Options -> Performance -> Rebuild symbol databases
Hopefully this will fix things for you, and everything will them work well.
As for thinking of Alt-G on a keyword, its a keyword, normally it would be pointless to do so, so its not something I would expect you to think of or try. Its one of those little tricks you learn when dealing with strange code problems  |
| kimbo |
Posted - Nov 06 2024 : 07:27:59 AM
Good hint to press alt+g on the "using" - why didn't I think of that myself??
Turns out, it jumps into a popular thirdparty header file, which is part of the solution and contains lots of compile time checks like:
#if defined(using)
#define using EMIT WARNING C4005
#error The C++ Standard Library forbids macroizing the keyword "using".
The code is sourrounded by some define checks (eg. "!defined(__INTELLISENSE__)").
When I remove this file from the vcxproj, the using works again. \o/
Is it possible to prevent VAX from parsing this file? Otherwise I will find a way with our custom build system.
And maybe it would be a good idea to ignore defines on c++ keywords in VAX?
|
| feline |
Posted - Nov 05 2024 : 06:11:56 AM
Thank you for trying this. The fact that a college doesn't have this issue is confusing though.
I can think of two basic reasons for this problem. First, one of your standard #include files contains a statement, that when present, causes this problem. If this was the case then the problem is likely to be file specific, so it could be that you and your colleague are looking at different files in the same solution, where one file has the problem and another file does not have the problem.
To test this, can you try opening / making a new, empty cpp file in your main solution, and trying the same test inside that file? This will tell us if its caused by something further up the file or not.
The other reason I can think of for this problem is something, probably a #define, in one of your library directories. This could be in a Windows SDK, or a 3rd party library you are using. If your colleague has a slightly different version of the SDK or library this could explain why you are seeing different results.
This isn't quite so easy to test. But can you please try placing the keyboard caret into "using" "typedef" and the struct and alias names and see what, if anything, is shown in VA's context and navigation fields. We are looking for anything odd, or any obvious differences in behaviour between what you see in the small test solution, where this works, and the same test in your main solution, where the problem is. If there is a difference, hopefully it will offer a clue as to where to start looking. |
| kimbo |
Posted - Nov 04 2024 : 08:33:33 AM
When I create an empty project, it's fine. A colleague doesn't have this issue on the same project. So I'm wondering what kind of settings can lead to this behaviour.
When I enable Intellisense, it looks like this:
Alt+G is working now (?) but VAX still doesn't show anything in the menu.
|
| feline |
Posted - Nov 04 2024 : 07:13:36 AM
I am wondering if this is a solution specific problem. To test this, can you please try making a new, default C++ solution and see if you see the same problem there?
It is possible you will see this problem on all solutions on this machine, but this is a quick and simple test, so a good place to start. |
| kimbo |
Posted - Nov 02 2024 : 11:43:09 AM
No, it's not a coloring problem. Alt+G doesn't work and the context fields are empty.
This is from a different VAX/VS version, but with the same code:
VA_X.dll file version 10.9.2511.0 built 2024.01.23
DevEnv.exe version 15.9.34729.27 Professional
|
| feline |
Posted - Nov 01 2024 : 07:44:25 AM
I am not seeing any problem with this sample here.
If you place the keyboard caret into "TestVax2" or any of your using types, what, if anything, is shown in VA's context and navigation fields? These are normally at the top of the editor window, and are where the Alt-M list appears from. Does Alt-G have any effect?
I am trying to find out if this is "just" a colouring problem, or if the problem goes deeper.
For me, the colouring is the same for both aliases, and Alt-G goes to the using line, and Alt-Shift-G lets me see the members of the underlying struct type. So it will be interesting to know how your results compare. |
|
|
