Visual Studio using default (non-visualgdb) text editor for header files

[john]

I discovered this problem through a weird intellisense issue – intellisense was discovering and parsing all headers, but wasn’t working properly inside those headers.

But I was able to confirm that it’s because Visual Studio is actually using the default editor for .h files. I disabled the horizontal scroll bar in “Text Editor->C/C++->Scoll Bars”, but left it enabled in “Text Editor->C/C++ (VisualGDB)->Scroll Bars”. Now there’s no horizontal scroll bar when opening .h files, but there is a horizontal scroll bar when opening .cpp files, confirming it’s using the default editor. This happens no matter what method I use to open .h files.

This introduces a whole host of problems – the VisualGDB project settings for intellisense, syntax highlighting, and clang-format are all ignored in favor of nonsense Visual Studio defaults for miscellaneous files.

I tried looking through the VS options to change the default association, but “Text Editor->File Extension” doesn’t have options in the editor dropdown for either C++ editor, default or VisualGDB.

What should I try for a fix or to gather more information on why this is happening?

[support]

Hi,

This likely happens because you have both VisualGDB-based and non-VisualGDB-based projects in your solution. We can help you troubleshoot this, however we would kindly ask you to renew your support first via this page: https://sysprogs.com/splm/mykey.

[john]

Went ahead and renewed support. You’re spot-on that the solution includes a non-VisualGDB project; it’s a Windows C++ console app. This gets compiled and then the VisualGDB embedded project calls it via batch script as a post-build step, in order to manipulate the output binary (it does some fiddly custom modifications that there aren’t command line Windows utilities for, and I’d rather roll my own than introduce a third party dependency to the build sequence.) It’s also listed first in the build order, because it needs to be ready at the end of compiling the embedded project.

Is there a way to fix the editor issue without changing this structure? It’s very tidy to have the console app be part of the solution, as it makes sure everything is properly tracked in source control and everything gets built, preventing confusion among developers who only touch the codebase rarely.

[support]

Hi,

Thanks for renewing your support.

If the solution contains multiple projects and you open a header (or source file), VisualGDB checks which of the projects explicitly reference that file. If the file is explicitly referenced by a non-VisualGDB project and not referenced by a VisualGDB-based project, it will let Visual Studio handle IntelliSense.

The workaround is extremely straight-forward: simply include the file in question in your VisualGDB-based project (Add->Existing file in the context menu). Since header files are not built directly, this won’t affect the build process, but will make sure VisualGDB uses the Clang IntelliSense engine when editing this file.

[john]

I actually already have all header files added to the VisualGDB project – I’m using a CMake-based project and every header file has a line in one of the static library’s CMakeList.txt file, inside add_bsp_based_library(). (The project is broken into libraries to help make unit testing a little easier.) If I use Add->Existing file I get an error stating that the file is already present (as expected.) Header files appear in the solution explorer under their respective static libraries.

I thought it might be an issue with the level of indirection introduced by the static libraries, so I added a header file to the top-level add_bsp_based_executable(), and the problem still persisted.

(Also, if it’s relevant, only a single header file is also cross-included in the console application. The rest are exclusive to the embedded project and aren’t registered to the console application project as sources.)

[support]

Thanks for clarifying this. CMake projects indeed handle the header files differently (depending on how CMake reports them and a few other settings), so some combination of settings might prevent IntelliSense from prioritizing them over the VS project.

We should be able to fix it promptly if you could create a simple repro case – a solution containing:

1. A basic Win32 C++ project referencing the header
2. A basic CMake-based project referencing the header the same way your current setup does it

If you can confirm that the problem persists in the repro solution, please try packing it into an archive and attaching it here (or using a file hosting service). BTW, the easiest way to check whether a file is using Clang IntelliSense is via the “Go” button on top of the file (see this page).

[john]

I was able to make the repro case very simple – it was sufficient to just create an advanced CMake project and add a windows console app project to the solution, I didn’t have to do any cross-referencing. Once I added the console app, attempting to open “stm32f7xx_hal_conf.h” opens without clang intellisense (no “go” button visible.)

Project archive attached, I made no edits to either project, it’s just the LED blink template for the embedded project and the hello world template for the console app.

Attachments:

You must be logged in to view attached files.

[support]

Thanks, we have reproduced the problem and found the root cause.

When CMake introduced a new optimized format for reporting CFLAGS for source files, we added a translation layer that allowed VisualGDB to handle both old and new formats. Turns out, the translation layer was not properly handling the sources that didn’t have any CFLAGS attached to them. This would only affect solutions with both VisualGDB and non-VisualGDB projects, and only when CMake would use the new code model format.

Either way, we have fixed the issue in the following build: VisualGDB-5.6.109.4813.msi

[Author]

Posts