Forum Replies Created
-
Posts
-
Yes, simply go to the IntelliSense Settings page of VisualGDB Project Properties and add “-include <forced include file>” to IntelliSense CFLAGS/CXXFLAGS.
You can change the syntax highlighting colors via Tools->Options->Environment->Fonts and colors->Text Editor. VisualGDB automatically uses the standard C/C++ colors from the normal Visual C++ package (if they are supported in your VS version) and adds a few elements of its own (e.g. “C++ Constructors and Destructors”).
Hi,
The easiest way to restore the broken Remote Console window would be to restore the .vgdbsettings file from your source control system. All debug settings are contained in that file and will be reverted by restoring it.
If that is not possible, please try creating a new project with the project wizard and see if remote console is broken there as well. If not, compare the settings in your project with the settings in the new project to see what can be causing the problem.
Hi,
VisualGDB currently does not support solution-wide variables. However, you can use 2 mechanisms to define things globally:
- Use SSH host aliases (see the SSH Host Manager window) to avoid hardcoding machine names in your projects.
- Reference environment variables using the same syntax as the per-project variables: $(VarName).
If this is insufficient, please let us know your scenario so that we could suggest a better solution.
Hi,
Can you attach a screenshot of the emmintrin.h file showing the error location and the color of tokens around it?
Does your project specify -std=xxx explicitly in compiler flags? Can you open View->Clang IntelliSense Status, switch to Project Status and share the value of CFLAGS and CXXFLAGS displayed there?
Please also confirm whether the problem happens while trying to edit a .c or .cpp file.
Hi,
I presume, you mean VisualGDB, not WinGDB. Yes, simply click “resynchronize toolchain” on the Build Settings page of VisualGDB Project Properties and VisualGDB will automatically fetch those files for you.
Hi,
You can specify NDK_MODULE_PATH via Make arguments in VisualGDB Project Properties (Build Settings page).
Hi,
You can specify NDK_MODULE_PATH via Make arguments in VisualGDB Project Properties (Build Settings page).
It might be possible in theory, but in practice many Cygwin-specific functionality will simply crash randomly because it will expect certain process-wide preparations to be made by the host executable (that will not be made as your EXE is not cygwin-based). You could try investigating and fixing those crashes, but using MinGW would be a much easier solution.
You do not need to copy the source code to the target machine. Although GDB running there won’t be able to locate the source files, it will report the file paths to VisualGDB. And as long as VisualGDB has the correct path mappings (configured via VisualGDB Project Properties), it will be able to map those paths to the correct source files on the Windows machine.
Hi,
Thanks for reporting this. Looks like VisualGDB missed one step in detecting the new library locations introduced in Android 5.0. Please try VisualGDB 5.0 Preview 4 and let us know if it works.
Hi,
Are you trying to load a Cygwin DLL into a non-Cygwin EXE? If yes, this is unsupported and can cause very strange bugs. I would recommend building your code with MinGW instead of Cygwin. It does not emulate certain Unix-world things like fork(), but is much easier to integrate with existing code from the Windows world.
