Forum Replies Created
-
Posts
-
Hi,
VisualGDB 5.2 should already be doing double-buffering for the parse data. I.e. while a file is being parsed, it will use the previous parse data to highlight local references and handle other similar functionality. The Ctrl-Space code completion should also work completely parallel to this. If you observe the opposite, please share the repro steps and the diagnostic log so that we could investigate this.
Ophidian14: we will try to include this feature in one of the early preview builds of v5.3. We will post an update here once it becomes available.
Hi,
For a 3rd-party toolchain you would need to manually specify “–specs=nosys.specs” via LDFLAGS to include the necessary libraries. The toolchains shipped by us have this flag conveniently mapped to a checkbox in the settings, but 3rd-party toolchains would require specifying it manually.
Hi,
VisualGDB does not have a free community edition. Please note that we only offer support to the users of our paid products like VisualGDB. To get general Qt-related support, please try asking on the Qt forums.
Hi,
Those are actually 2 different processes. The long one-time indexing (that uses all CPU cores) happens one time after you import a project and builds a large database of all cross-references in your code, so you can instantly execute commands like “Find all references”. The 7169 msec check mentioned in the log file above only checks one single source file and should normally happen in the background and not cause any delays (as long as you are using v5.2, code completion and other IntelliSense functionality can run in parallel with the long “Parse – Check” operation).
The bootstrap script (and other autotools) don’t work very well on Windows.
We would recommend getting a checkout of our OpenOCD fork that uses CMake and manually merging it with the latest code from the main OpenOCD repository. We will also do that on our side in the next couple of weeks, so you can simply wait for that.
Hi,
Oops. Sorry about that. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.16.1467.msi
Hi,
Sorry, this does not look like a VisualGDB-related bug. Normally it should not touch anything unless you go beyond the run-as-admin stage. This could be caused by some sort of a VS registry corruption or a corrupt installation. We would recommend trying to move away VS-related folders in your user account and restarting Visual Studio to recreate those folders.
Hi,
Thanks, it’s a known issue. This happens due to limitations of the WinForms technology used by VisualGDB to show GUI. We are gradually switching our GUI to the newer WPF technology that should resolve this.
We have also received feedback that WinForms GUI looks better on high resolution displays after installing the Windows 10 Creators Update.
This could happen if the other file is not a part of the project. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.16.1466.msi
It should print the lookup progress to the window available via View->Clang IntelliSense Diagnostics Console.
Hi,
We usually respond faster to issues that do not require thorough investigation (like crash dumps). We will follow up on the crash dumps once we have more information about the cause.
Hi,
Thanks, looks like a toolchain bug. Can you reproduce this with the command-line ESP-IDF environment as well?
Hi,
Thanks, actually looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.16.1464.msi
Hi,
Good to know it works. BTW, VisualGDB should be able to install even if the VS is installed to a custom directory. So we would really appreciate it if you could let us know the details on your previous installation parameters so that we could reproduce it and ensure VisualGDB would detect it properly.
