C/C++ Editor Settings

Sysprogs forums Forums VisualGDB C/C++ Editor Settings

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #12624
    UdoEberhardt
    Participant

    Hi,

    I do a lot of Windows development and some embedded development as well. Hence I’m happy I found VisualGDB because it enables me to write and debug the embedded C++ code in my preferred IDE and editor. I’m currently evaluating VGDB and now I found that obviously it uses its own set of editor settings under Tools->Options->Text Editor->C/C++ (VisualGDB). This means I have to go through tons of settings and adjust them to achieve the same behavior as with the standard C++ editor.

    Questions:

    Why does VGDB use separate editor settings?

    What happens if I combine Windows projects and VGDB projects in one solution?

    What if there are some C++ files shared between both project types? I do have many such files. These are referenced by Windows projects and embedded projects at the same time.

    Is there a way to force VGDB to use the general C++ editor settings?

    Thanks.
    Udo

     

    #12634
    support
    Keymaster

    Hi,

    VisualGDB includes a separate IntelliSense engine optimized for GCC-specific code (like most embedded libraries), so its settings generally differ from the regular C++ settings. That said, VisualGDB detects and imports most common C/C++ language settings from the regular C/C++ pages, so you don’t need to set the same settings twice. If you believe this is not the case for some settings, please let us know and we will investigate.

    You can easily combine VisualGDB projects and regular Win32 projects in one solution. If the same file is shared between VisualGDB and a non-VisualGDB project, VisualGDB will rely on Visual Studio to determine the project corresponding to the file. Depending on the VS version and settings, it may treat it as a part of the VisualGDB project or as a part of the regular VC++ project.

    If this causes confusion, we would advise temporarily unloading irrelevant project during development so that Visual Studio could uniquely identify the projects for all source files.

    #12661
    UdoEberhardt
    Participant

    Thanks for your reply. I understand that the Intellisense engine requires a different set of options. However, in my case I had to manually adjust basic editor settings such as tab size manually. I do not remember exactly what I had to tweak but I’m sure about the following observations:

    I installed VisualGDB over an existing VS2015 installation with the following settings under
    Tools->Options->Text Editor->C/C++->Tabs: Indenting = Block, Tab Size = 4, Insert Spaces.

    After that under Tools->Options->Text Editor->C/C++ (VisualGDB)->Tabs I had:
    Indenting = Smart, Tab Size = 4, Keep Tabs.

    Also settings from the General section were not imported by VisualGDB. I have “Line numbers” checked which I had to redo in  the (VisualGDB)->General section.

    Also Text Editor->C/C++->Formatting->General->”When I past: Do nothing” was not converted to
    Text Editor->C/C++ (VisualGDB)->Formatting->Auto-format when pasting text.

     

    I think it’s okay to offer a different set of Intellisense options. But VisualGDB should not duplicate editor and auto-formatting settings. The editor settings reflect my personal preferences which should be in effect when I work on any C++ code. Whether the target is embedded or PC does not make a difference here. In other words, such settings are language-specific but not target-specific.

    Udo

     

    #12694
    support
    Keymaster

    Hi,

    Thanks for clarifying this. The common settings (like tab sizes) are unfortunately managed by the VS language service mechanism, so they have to be separate. All advanced formatting settings that come from VisualGDB (like indentation for classes/namespaces/functions) are actually inherited from the regular VC++ settings.

    We understand this is annoying, however as the workaround is relatively simple (changing a very small set of options once), we don’t want to go hacking the language service internals and risk breaking something on a higher scale, sorry.

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.