Forum Replies Created
-
Posts
-
Hi,
Thanks for your suggestion, however this is something to ask from the Resharper developers. We don’t have access to the Resharper’s source code and cannot modify it to work with the Clang IntelliSense.
Hi,
Thanks, looks like VisualGDB was not properly recording some uses of the macros. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.6.2459.msi
Hi,
Thanks for the suggestion. We are actually experimenting with providing CodeLense-like interactive popups for visualizing and navigating relations between functions, classes and other entities. The functionality you are suggesting sounds like a good fit for that new mechanism, so we will likely add it there.
Hi,
It shouldn’t cause any extra problems, but it will trigger the same issue is you use the pre-packaged toolchain (as the problem is due to missing packages in the toolchain and not in VisualGDB). If you use a different toolchain (e.g. build one from scratch) and it works, you can easily use it with VisualGDB as well by copying the toolchain.xml file and esp32-bsp folder from our toolchain to it and importing it into VisualGDB.
Hi,
OK, thanks for clarifying this. The exact steps depend on your project type. Are you using MSBuild, GNU Make, QMake or CMake?
Hi,
We have just rested everything. The ESP-IDF v3.1 works as expected. Trying out the master branch indeed results in errors.
It looks like a known bug of the latest ESP-IDF and Espressif might be working on resolving it. As one of the comments on the bug thread mentions, you might be able to get it to work by rebuilding the toolchain from scratch (let us know if you need help getting VisualGDB to recognize the rebuilt toolchain), but if you don’t want to spend time diagnosing incompatibility between different components, we would simply advise waiting until Espressif fixes this (we will update our toolchain accordingly once they release a stable package compatible with the master branch).
Hi,
No worries. Sometimes the names in the SDKs can be indeed confusing and we are happy to point you to the right direction.
Hi,
This message itself does not indicate any error, it simply means that the target has stopped at a breakpoint. Please let us know what exactly you are doing, what are you observing/expecting and share the ENTIRE output of the OpenOCD window and the GDB Session window (after you switch it to the “All GDB Interaction” mode).
Hi,
Normally all you need to do is switch the active configuration from Debug to Release in Visual Studio. Unless you have explicitly deleted the release configuration, it should be already present.
The VS configuration selector is typically found on the toolbar near the undo/redo buttons. If you are not sure, please attach a screenshot of your VS window and we will help you find it.
Hi,
This is by design. The Quick Info will use the declaration that could be found by parsing just the current source file (or more likely simply fetching it from the cache created when you opened/saved it). The Go-to-Definition relies on a project-wide cache that may take longer time to update (as the function might be defined in a different file). If you are interested in previewing the function definition, please use the “Peek Definition” command instead.
Hi,
Indeed the new toolchain in based on a different environment (MSYS2 vs Cygwin) and hence requires VisualGDB 5.4 Preview 6 or later in order to work correctly.
Hi,
Sorry for the confusion. We have rechecked the repro steps you mentioned and were able to reproduce them, however we also reproduced them when building the project from command line outside VisualGDB (using idf.py), so the problem is likely caused by some other difference between the 2 projects.
Please try building the modified “hello, world” project using the regular VS CMake interface. Does it still work as expected?
If yes, please try building the project manually from an MSYS2 shell using the CMake version from VisualGDB (under %LOCALAPPDATA%\VisualGDB\CMake) and then using the CMake version used by Visual Studio. If this produces different results, please let us know the CMake version used by the regular VS.
P.S. VisualGDB now officially supports CMake-based ESP-IDF projects. Please consider updating to v5.4 Preview 6.
Hi,
Most likely you have defined the macro after the Qt header files were included. Either way, we have added the definition to ignore __declspec() to VisualGDB 5.4 Preview 6. Please feel free to update to this version – it will automatically skip __declspec() in your code.
Hi All,
Just wanted to share an update that we have added support for resource folders to the CMake-based ESP-IDF projects (and other Advanced CMake projects) to VisualGDB 5.4 Preview 6.
You can use the Add->Pin a Resource Folder in Solution Explorer command to attach an arbitrary folder with the specified file masks to Solution Explorer.
Sorry for the delay. We were running the final tests on the new VisualGDB 5.4 Preview 6 that considerably improves the ESP-IDF experience and have just released it.
Please try downloading VisualGDB 5.4 Preview 6 and then update your ESP32 toolchain to the latest version. Please try using CMake instead of the regular GNU Make when creating the project – it should result in much faster build speed.
Let us know if you encounter any problems with the new toolchain and VisualGDB build and we will be happy to help.
