I'm just diving into VC++ after a number of years in other areas of programming. I am puzzled by the errors that come up when I go from a debug version to a release version. I'm probably doing something stupid here...
For example, this code works fine for debug compiles:
ofn.lpstrFile = (LPSTR)title;
However, if I go to release mode, I get an error and have to put in a W:
ofn.lpstrFile = (LPWSTR)title;
What am I doing wrong? This is not a MFC program, it's really just a very simple program where I read a file, take the information from it to eliminate certain parts of another file, and then write the final file to disc.
This is because you have different settings in the Debug and Release configuration. Your debug configuration is set to have the character set "Not set" while the Release configuration is using "Use Unicode character set".
To change the character set go to the project properties, select your configuration and from Configuration Properties > General > Character Set select the same for all your configurations.
Related
Hello i build 32 and 64 bit version wxwidget (Batch Build and select all) from source code without any problems. Then add path to the system variables as named "WXWIN" with C:\wxwidget (there is wxwidget source)
In visual studio 2019 in solution i add these path's:
C/C++ -> Additional Include Directories ->
$(WXWIN)\include
$(WXWIN)\include\msvc
Linker -> Additional Library Directories ->
$(WXWIN)\lib\vc_lib $(WXWIN)\lib\vc_lib\mswud
But i got error in visual:
Severity Code Description Project Path File Line Suppression State
Error (active) E1696 cannot open source file
"../../../lib/vc_lib/mswd/wx/setup.h" guiwxwidget C:\wxwidgets\include\wx C:\wxwidgets\include\wx\setup.h 140
And i dont know whats wrong with it.
I try also recompile 4x wxwidget source without any progress.
Your project is not configured to use Unicode, hence it tries using non-Unicode build of wxWidgets (note the missing u in mswd/wx/setup.h) which is not available. You should ensure that the "Character Set" option in the "Advanced" section of your project properties is set to "Use Unicode Character Set".
The strange thing is that this should be the default, so it looks like you might have changed it intentionally. If you really did, you will need to build wxWidgets in (deprecated and soon to be removed) ANSI build mode, but it's much better to leave this option at its default value and use Unicode -- we're in 2021, after all, not 1991.
I'm very new to c++ and was getting this error while trying to build Release versions of my c++ OpenGL project. After some googling I went ahead and changed the Runtime Library in the C/C++ > Code Generation menu to Multi-Threaded Debug GLL (/MDd), which then fixed the issue. I'm wondering if that's the right thing to do though.
I created a new empty project as a test, and the default Runtime Library setting in Release mode is Multi-Threaded (/MD). The default Runtime Library for Debug mode is Multi-Threaded Debug (/MDd). Despite having different Runtime Libraries, both configs build successfully, which makes me wonder if there's been a mess up in my project setup at some point.
Another detail that made me curious was the output log while trying to build in Release x64:
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\LoggerFactory.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\ConsoleAndFileLogger.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Component.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Physics.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Rotator.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\IEntitySpawnHandler.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\SpaceScene.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\ActionManager.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\DeviceManager.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Device.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Mouse.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\MouseAxis.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\MouseButton.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\InputAction.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\InputAxis.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Scene.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\GUI.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\GLFWKeyboardKeyData.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Keyboard.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\GLFWPCInputDeviceFactory.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Random.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\IndexBuffer.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Main.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Material.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Mesh.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\OpenGLUtilities.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Square.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Shader.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\ShaderManager.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\VertexArray.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\VertexBuffer.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\SceneManager.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Singleton.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\glm.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\imgui.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\imgui_demo.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\imgui_draw.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\imgui_impl_glfw_gl3.obj
**D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\x64\Release\Window.obj
**D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Camera.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Color.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Debug.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\ObjectRenderer.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Entity.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\SpaceShip.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Star.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Input.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\KeyboardKey.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Math.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Renderer.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Time.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Transform.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Vector2.obj
D:\Documents\_Projects_FAT\Gios_OpenGL\bin\intermediates\Win32\Debug\Vector3.obj
I've highlighted two lines where the intermediate file path changes from bin\x64\Release to bin\intermediates\Win32\Debug, and was wondering if this might help with the issue.
Though not a perfect solution, I ended up creating a new project and reimporting all dependencies one after another, compiling in between to try and find the issue. After importing all libraries, the new project just worked. I then copied all of my code and compiled it in the new solution, which worked, so the issue has been resolved.
I saved a diff between the two project files, but couldn't find the issue (they are too different for me to make sense out of). Maybe someone with more experience can figure it out.
I made a simple hello world program. I clicked on "Start Debugging" and the window showed "Project is out of date. Would you like to build it?" As I click on "yes", the next window shows "There were build errors. Would you like to continue and run the last successful build?". I choose yes again, and it shows this window: (attached screenshot)enter image description here
There were build errors. Would you like to continue and run the last successful build?
The only correct answer to that question is "No". If you clicked "Debug", you obviously want to debug the current version of the source, not some stale old version that won't match what you're seeing in the editor.
Disable this nonsense message in Tools → Options → Projects and Solutions → Build and Run. For "On Run, when projects are out of date", set it to "Always build". For "On Run, when build or deployment errors occur", set it to "Do not launch".
I cannot think of a reason why you ever want the other options as default settings. If you want to launch an old, stale build, you can always do so manually.
I choose yes again, and it shows this window: "The system cannot find the file specified."
Yet another reason why this is a stupid setting. The second one in particular, the one that controls Run behavior when build errors occur.
What happens is, when you tried to build the project, the first step was to do a clean, which effectively means delete the old files. With the old files gone, it kicks off a build. The build fails, you get an error. You ask it to ignore the error and run an old version. But wait! The old version got deleted at the start of the build, so it no longer exists!
If a build fails, return to the IDE, fix the errors, and then relaunch to rebuild.
Bonus: The build error that you're getting is "fatal error C1010", which is a rather silly error that can be very confusing to those unaccustomed to Visual Studio. Basically, what it's telling you is that because you are using precompiled headers (the default for new projects), the very first line in every source file needs to be the inclusion of your precompiled header. By default, it is named stdafx.h, so the first line in your code file should be:
#include "stdafx.h"
This should go before you include the system header <iostream>. The precompiled header must be included at the very top of the file, or you'll get a build error.
If you do not like that, then you can turn off precompiled headers:
Right-click on your project in the Solution Explorer, and choose Properties.
At the top, click the "Configuration" combobox and select "All Configurations".
Expand "C/C++" in the tree view, and select "Precompiled Headers".
Set the top option, "Precompiled Header", to "Not Using Precompiled Headers".
Sorry: your last successful build was deleted earlier - possibly as a result of an attempted compile/link. You need to fix the source code that you've got now before you've got anything to debug...
It seems to appear that some .dll files are missing for the debug mode for many users.
You don't need to run the debug mode for this, if your program works on normal running, then let it run.
I also can see that you wrote void main() but in C++ the good syntax is int main() and terminated by a return 0; instruction. By the way, think about letting at least a space between #include and the libraries like <iostream> here.
Why doesn't 'Edit & Continue' feature work in VS2015?
The debugger will ignore the edit and you will see an error message when you continue execution and I get the following
“The source file has changed. It no longer matches the version of the
file used to build the application being debugged.”
You must set the Debug Information Format to be “Program Database for Edit and Continue (/ZI)”. If this option is incorrectly set the debugger will ignore the edit, it will be just like modifying a file with edit and continue disabled.
If you make an edit in a binary not compiled with this option, the debugger will ignore the edit and you will see an error message when you continue execution “The source file has changed. It no longer matches the version of the file used to build the application being debugged.”
Open the Property Pages of the project.
Under Configuration Properties -> C/C++ -> set the Debug Information
Format to “Program Database for Edit and Continue (/ZI)”
Edit & Continue has only been introduced in VS2015, therefore this option is not available on earlier versions.
I am using code::blocks.
I set up the MSVC compiler(downloaded the MSVC Express 2010 Compiler and then added SDK directories).
The project does compile, however when I try to debug it ingores the breakpoints I set.
If I go Settings->Compiler->Toolchain Executables, the chosen Compiler is GDB/CDB : Default.
I guess the problem is gdb cannot debug msvc code. But how do I add a ne debugger?
In Settings->Debugger there is only one option of GDB/CDB compiler and I cannot add new one.
I tried adding additional directories, but it doesn't help.
So how do I make it work?
thanks
It's in Settings/Debugger and not in in Settings/Compiler/Toolchain Executables.
Got the same problem... I set path for cdb in code::blocks, ensured that the compiler added debug info, did everything I found on google (set Symbol Path to some weird stuff as described here: http://forums.codeblocks.org/index.php/topic,8454.msg63355.html#msg63355 and here: http://msdn.microsoft.com/en-us/library/windows/hardware/hh439323%28v=vs.85%29.aspx) - and still nothing. I didnt have any errors in debuger log, but it still wouldn't work. Finally - EUREKA: http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks#Path_with_spaces
Breakpoints could not work if the path/folder you've placed your
project contains spaces or other special characters. To be safe use
English letters, digits and '_'.
After changing " " to "_" in directory names - everything works fine. And I lost only 5 hours for that...