System info topics.
Error C2664 'RPC_STATUS UuidFromStringW(RPC_WSTR,UUID *)': cannot convert argument 1 from 'TCHAR *' to 'RPC_WSTR' EnumDevices
Error C1189 #error: Building MFC application with /MD[d] (CRT dll vers
XML parsing or parsers
research on TCHAR vs. UNICODE.
tips on MFC project compiling. one tip is how to use comctl32.dll. I read some reminders on the book "MFC from ground up", such as we must invoke initinstance(). this post explains why.
So to conclude, what I learned because of message box problem is:
how to set up additional include libraries such as comctrl32.dll to include common control library.
Please don't reply to the post as I have solved it myself. The reason I hav'nt deleted the post is just in case anyone else comes across the problem.
Well, I sometimes can't see the wood for the trees so I apologise for any inconvenience this has caused! To link the comctl32.lib, ( not .dll and in lowercase ), I found the linker command line in Visual C++ 2008 Express Edition and added it there, thus for anyone else;
Project >> Properties >> Congifuration Properties >> Linker >> Command Line
Then simply add comctl32.lib and away you go!
Oh, and don't forget "#include <commctrl.h>"
viewport concept research. search "viewport" in codeproject.com
very good test on concept of GDI+ in C#. I need to take a look at it to use this in my PF application.
above posts are related with viewport.
screen printing topic
Win32 leagacy recompilation error fixes
Error C1189 #error:
MFC does not support WINVER less than 0x0501. Please change the definition of WINVER in your project properties or precompiled header. PrintDlg c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.16.27023\atlmfc\include\afxv_w32.h 40
o modify the macros, in a header file (for example, in targetver.h, which is included by some project templates that target Windows), add the following lines.
#define WINVER 0x0A00
#define _WIN32_WINNT 0x0A00
usually defining these macro in stdAfx.h file is good.
Error D8016 '/ZI' and '/Gy-' command-line options are incompatible
solution is:
the same issue got, resolved by changing Project ➔ Properties ➔ C/C++ ➔ General ➔ Debug Information Format ➔ Program Database (/Zi)
Error C2664 'int StringFromGUID2(const GUID &,LPOLESTR,int)': cannot convert argument 2 from 'USHORT [100]' to 'LPOLESTR'
Error C2440 '=': cannot convert from 'const char [6]' to 'LPSTR' Tooltips c:\demo\tooltips\tooltips\tooltips.cpp 292
code snippet is: ((NMTTDISPINFO*)hdr)->lpszText = "Lines"; when I build tooltip project in Visual C++ project.
My solution:((NMTTDISPINFO*)hdr)->lpszText = (LPSTR)"Lines";
this is official explanation from Microsoft.
some issues fix on building menu resource file.
#include afxres.h or #include windows.h can fix this issue in resource file definition.
the answer is:
Or, if you don't want to install MFC, you can replace the line:
#include "afxres.h"
with:
#include
In the newest version of Visual Studio 2017 this seems to have been separated into two components that needs to be installed. 1)Visual C++ ATL for x86 and x64 2)Visual C++ MFC for x86 and x64
Tools -> Get Tools and Features... will list what components are installed and allow for adding and removing of components.
answerThis header is a part of the MFC Library. VS Express edition doesn't contain MFC. If your project doesn't use MFC you can safely replace afxres.h with windows.h in your terrain2.rc.
Even I too faced similar issue: fatal error RC1015: cannot open include file 'afxres.h'. from this code Replacing afxres.h with Winresrc.h and declaring IDC_STATIC as -1 worked for me. (Using visual studio Premium 2012)
//#include "afxres.h" #include "WinResrc.h" #define IDC_STATIC -1
Alternatively you can create your own afxres.h:
#ifndef _AFXRES_H
#define _AFXRES_H
#if __GNUC__ >= 3
#pragma GCC system_header
#endif
#ifdef __cplusplus
extern "C" {
#endif
#ifndef _WINDOWS_H
#include
Microsoft C++ porting and upgrading guide
This article provides a guide for upgrading Microsoft C++ code to the latest version of Visual Studio. For projects created in Visual Studio 2010 through 2015, just open the project in Visual Studio 2019. You can upgrade a Visual Studio 2008 or earlier project in two steps. Use Visual Studio 2010 to convert the project to MSBuild format first. Then open the project in Visual Studio 2019. For complete instructions, see Upgrading C++ projects from earlier versions of Visual Studio.
The toolsets in Visual Studio 2015, Visual Studio 2017, and Visual Studio 2019 are binary-compatible. Now you can upgrade to a more recent version of the compiler without having to upgrade your library dependencies. For more information, see C++ binary compatibility 2015-2019.
To upgrade a project created in an earlier version of Visual Studio, just open the project in the latest version of Visual Studio. Visual Studio offers to upgrade the project to the current schema.
If you choose No, the project doesn't get upgraded. For projects created in Visual Studio 2010 and later, you can still use the project in the newer version of Visual Studio. Just set your project properties to continue to target the older toolset. If you leave the older version of Visual Studio on your computer, its toolset is available in later versions. For example, if your project must continue to run on Windows XP, you can upgrade to Visual Studio 2019. You then specify the toolset as v141_xp or earlier in your project properties. For more information, see Use native multi-targeting in Visual Studio to build old projects.
If you choose Yes, then the project gets upgraded in place. It can't be converted back to the earlier version. In upgrade scenarios, that's why it's good practice to make a backup copy of the existing project and solution files.
Over the years, the Microsoft C++ compiler has undergone many changes, along with changes in the C++ language itself, the C++ Standard Library, the C runtime (CRT), and other libraries such as MFC and ATL. As a result, when upgrading an application from an earlier version of Visual Studio you might encounter compiler and linker errors and warnings in code that previously compiled cleanly. The older the original code base, the greater the potential for such errors. This overview summarizes the most common classes of issues you are likely to encounter, and provides links to more detailed information.
Note In the past, we have recommended that upgrades that span several versions of Visual Studio should be performed incrementally one version at a time. We no longer recommend this approach. We have found that it's almost always simpler to upgrade to the most current version of Visual Studio no matter how old the code base.
n Visual Studio 2015, the Microsoft C Runtime Library (CRT) was refactored. The Standard C Library, POSIX extensions and Microsoft-specific functions, macros, and global variables were moved into a new library, the Universal C Runtime Library (Universal CRT or UCRT). The compiler-specific components of the CRT were moved into a new vcruntime library.
The UCRT is now a Windows component, and ships as part of Windows 10. The UCRT supports a stable ABI based on C calling conventions, and it conforms closely to the ISO C99 standard, with only a few exceptions. It is no longer tied to a specific version of the compiler. You can use the UCRT on any version of Windows supported by Visual Studio 2015 or Visual Studio 2017. The benefit is that you no longer need to update your builds to target a new version of the CRT with every upgrade of Visual Studio.
the path information is listed in this link.
When you use the Windows SDK, you can specify which versions of Windows your code can run on. The preprocessor macros WINVER and _WIN32_WINNT specify the minimum operating system version your code supports. Visual Studio and the Microsoft C++ compiler support targeting Windows 7 SP1 and later. Older toolsets include support for Windows XP SP4, Windows Server 2003 SP4, Vista, and Windows Server 2008. Windows 95, Windows 98, Windows ME, Windows NT, and Windows 2000 are unsupported.
When you upgrade an older project, you may need to update your WINVER or _WIN32_WINNT macros. If they're assigned values for an unsupported version of Windows, you may see compilation errors related to these macros.
Microsoft has published the source code for the Standard Library, most of the C Runtime Library, and other Microsoft libraries in many versions of Visual Studio. The intent is to help you understand library behavior and to debug your code. One side-effect of publishing the library source code is that some internal values, data structures, and functions are exposed, even though they are not part of the library interface. They usually have names that begin with two underscores, or an underscore followed by a capital letter, names that the C++ Standard reserves to implementations. These values, structures, and functions are implementation details that may change as the libraries evolve over time, and so we strongly recommend against taking any dependencies on them. If you do, you risk non-portable code and issues when you try to migrate your code to new versions of the libraries.
Sometimes when you upgrade your projects to a newer version of Visual Studio, you may find that the results of certain floating-point operations have changed. This generally happens for one of two reasons: Code generation changes that take better advantage of the available processor, and bug fixes or changes to the algorithms used in math functions in the C runtime library (CRT). In general, the new results are correct to within the limits specified by the language standard. Read on to find out what's changed, and if it's important, how to get the same results your functions got before
Normally, we recommend that you update your projects when you install the latest version of Visual Studio. The cost of updating your projects and code is usually more than offset by the benefits of the new IDE, compiler, libraries, and tools. However, we know that you may not be able to update some projects. You may have binaries that are tied to older libraries or platforms that for maintenance reasons you can’t upgrade. Your code may use non-standard language constructs that would break if you moved to a more recent compiler. Your code might rely on 3rd party libraries compiled for a specific version of Visual C++. Or you may produce libraries for others that must target a specific older version of Visual C++.
Fortunately, you can use Visual Studio 2017 and Visual Studio 2015 to build projects that target older compiler toolsets and libraries. You don't have to upgrade a Visual Studio 2010, Visual Studio 2012, Visual Studio 2013, or Visual Studio 2015 project to take advantage of new features in the IDE:
Support for Windows XP development Visual Studio 2019 and later does not include support for creating code for Windows XP by using the v142 toolset. Support for Windows XP development by using the v141 toolset that shipped in Visual Studio 2017 is available as an optional component in the Visual Studio Installer. For information on how to install the v141 Windows XP platform toolset, see Configuring programs for Windows XP.
The MSBuild system for C++ projects was introduced in Visual Studio 2010. In Visual Studio 2008 and earlier releases, the VCBuild system was used. Certain file types and concepts that depended on VCBuild either do not exist or are represented differently in MSBuild. This document discusses the differences in the current build system. To convert a Visual Studio 2008 project to MSBuild, you must use Visual Studio 2010. After the project is converted, you should use the latest version of Visual Studio to upgrade to the current IDE and compiler toolset. For more information, including how to obtain Visual Studio 2010, see Instructions for Visual Studio 2008.
Visual Studio helps you upgrade legacy C++ code with compiler options, code analysis warnings, and editor features such as Quick Fixes, Quick Info, and the enhanced scroll bar. The term "legacy code" refers to any of these categories. this section contains a demo.
Code that was formerly allowed by the Microsoft C++ compiler (MSVC) but never conformed to the C++ standard.
To upgrade older non-conformant MSVC code, turn on the /permissive- compiler option. All instances of non-conformant usages are underlined with red squiggles in the code editor. The error messages in the Error List window include a recommendation for how to fix the error. Click on the error code to go to its help page in the documentation. If fixing all the errors at once is impractical, you can upgrade non-conformant code in stages by turning on the permissive- option, fixing some errors, then turning the option off again. The code will compile with the new improvements, and you can go back and fix the remaining issues at a later time. See the /permissive- page for examples of non-conformant MSVC code.
Code that was permitted in an earlier version of the C++ standard but has been deprecated or removed in a later version.
To upgrade to a newer language standard, set the C++ Language Standard option to the desired standard and fix any compile errors that are raised. In general, we recommend setting the language standard to /std:c++17. The errors raised when upgrading to a newer standard are not related to the errors raised when using the permissive- option.
Code that conforms to all versions of the standard but is no longer considered best practice in modern C++.
create C++ prooject in Visual Studio 2019. here are complete list of post to configure Visual Studio 2019.
A Visual Studio project is a project based on the MSBuild build system. MSBuild is the native build system for Visual Studio and is generally the best build system to use for Windows-specific programs. MSBuild is tightly integrated with Visual Studio, but you can also use it from the command line. For cross-platform projects, or projects that use open-source libraries, we recommend using CMake projects in Visual Studio in Visual Studio 2017 and later. For information about upgrading MSBuild projects from older versions of Visual Studio, see the Microsoft C++ Porting and Upgrading Guide.
In the IDE, all information that is needed to build a project is exposed as properties. This information includes the application name, extension (such as DLL, LIB, EXE), compiler options, linker options, debugger settings, custom build steps, and many other things. Typically, you use property pages to view and modify these properties. To access the property pages, choose Project > projectname Properties from the main menu, or right-click on the project node in Solution Explorer and choose Properties.
To create a custom group of settings that you can share with others or reuse in multiple projects, use Property Manager to create a property sheet (.props file) to store the settings for each kind of project that you want to be able to reuse or share with others. Using property sheets are far less error-prone than other ways of creating "global" settings.
The Visual Studio project system is based on MSBuild, which defines file formats and rules for building projects of any kind. MSBuild manages much of the complexity of building for multiple configurations and platforms, but you need to understand a little bit about how it works. This is especially important if you want to define custom configurations or create reusable sets of properties that you can share and import into multiple projects.
You can override project properties and targets from the MSBuild command prompt without changing the project file. This is useful when you want to apply some properties temporarily or occasionally. It assumes some knowledge of MSBuild. For more information, see MSBUild.
Often, a C++ project needs to call functions or access data in a binary file such as static library (.lib files), DLL, Windows Runtime component, COM component, or .NET assembly. In these cases, you have to configure the project so that it can find that binary at build time. The specific steps depend on the type of your project, the type of the binary, and whether the binary is being built in the same solution as your project.
This topic describes best practices for organizing project output files. Build errors can occur when you set up project output files incorrectly. This topic also outlines the advantages and disadvantages of each alternative for organizing your project output files.
A custom build tool provides the build system with the information it needs to build specific input files. A custom build tool specifies a command to run, a list of input files, a list of output files that are generated by the command, and an optional description of the tool. For general information about custom build tools and custom build steps, see Understanding Custom Build Steps and Build Events.
You can use build events to specify commands that run before the build starts, before the link process, or after the build finishes.
Build events are executed only if the build successfully reaches those points in the build process. If an error occurs in the build, the post-build event does not occur; if the error occurs before the linking phase, neither the pre-link nor the post-build event occurs. Additionally, if no files need to be linked, the pre-link event does not occur. The pre-link event is also not available in projects that do not contain a link step.
In Visual Studio, you can port existing code files into a C++ project using the Create New Project From Existing Code Files wizard. This wizard creates a project solution that uses the MSBuild system to manage source files and build configuration. It works best with relatively simple projects that do not have complex folder hierarchies. The wizard isn't available in older Express editions of Visual Studio.
Porting existing code files into a C++ project enables the use of native MSBuild project management features built into the IDE. If you prefer to use your existing build system, such as nmake makefiles, CMake, or alternatives, you can use the Open Folder or CMake options instead. For more information, see Open Folder projects for C++ or CMake projects in Visual Studio. Both options let you use IDE features such as IntelliSense and Project Properties.
A release build uses optimizations. When you use optimizations to create a release build, the compiler will not produce symbolic debugging information. The absence of symbolic debugging information, along with the fact that code is not generated for TRACE and ASSERT calls, means that the size of your executable file is reduced and will therefore be faster.
pew-compiled header
You can set compiler options for each project in its Visual Studio Property Pages dialog box. In the left pane, select Configuration Properties, C/C++ and then choose the compiler option category. The topic for each compiler option describes how it can be set and where it is found in the development environment. See MSVC Compiler Options for a complete list.
Linker options can be set inside or outside of Visual Studio. Within Visual Studio, you access linker options by right-clicking on a project node in Solution Explorer and choosing Properties to display the property pages. Choose Linker in the left pane to expand the node and see all the options
This section contains topics about targeting 64-bit x64 hardware with the Visual C++ build tools. a good gateway to more links.
It's interesting that the trick that I use isn't in the answers:
Don't change any CPP file; keep your header files as they are. Build as-is.
No typing, no RSI, no hassle with include paths, no other pain and misery. And the beauty is that it will still work when you move your solution to another platform. Awesome.
CEdit box
Far pointers are a specialty of the 8086 architecture. Unless you are going to write DOS or Windows 16 programs, you won't ever need to use them. Far pointers aren't part of standard C either and do not exist on other platforms.
Answer from Link #1 is good and clear one:If does nothing unless you happen to be using a 16 bit x86 compiler.
If you look in the Win32 header WinDef.h (in Visual Studio, simply right-click the word FAR in the source and select "Go to Definition", you will see that it is a macro defined as far, which in turn is also a macro defined as nothing at all!
It is only there to allow the compilation of legacy Win16 source as Win32. In 16 bit x86 compilers, far was a compiler extension keyword to support seg::offset pointers which resolve to a 20bit address (16 bit x86 only had a 1Mb address space!). They are distinct from 16 bit near pointers which comprised only the ::offset from the current segment.
dialog based appliction -tips and tricks
Severity Code Description Project File Line Suppression State:
Error C3861 'EndDiaglog': identifier not found Dialog2 c:\demo\dialog2\dialog2\dialog.cpp 86
above three posts are related..
Win32: baremetal programming.
google: c++ rc file tutorial
DLL basics
some comments are really good:
I'm fairly new to C++ and have been trying to follow this example after struggling on my own. But the problem I've got is I can't seem to get Visual Studio to create a .lib file, have you got any suggestions? Because without the .lib I can't link it into my projects... :S
You will have do the following. 1. Right click on your project on solution explorer and click "Properties". 2. Expand the "Linker" item in the tree. 3. Click on "Input" 4. Type in the name of your def file in the case of this example it would be "EasyDll.def" in the text box beside "Module Definition File". 5. Selection "Release" from the configuration dropdown box at the top left and enter in "EasyDll.def" to make sure that you also are given a .lib file when you compile for release mode too. Cheers,
Windows 98 basic concepts:: Win32 programming
this configuration section has good code snippet to test all these functions and get/set the parameters. good to practice them.
tips on fixing compilation error of temp file cleaning tool
Error D8016 '/ZI' and '/Gy-' command-line options are incompatible DirClean C:\Demo\dirclean\cl
Note: If you get the error “ Command line error D8016: '/ZI' and '/Gy-' command-line options are incompatible” -
Solution 1 : Use “Release” mode
Solution 2 : Go to “Project”>”Properties”>”C/C++”>”General” and replace the “Debug Information Format” from “/Zl” to “/Zi”
issue:: Error C1189 #error: MFC does not support WINVER less than 0x0501. Please change the definition of WINVER in your project properties or precompiled header. DirClean c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.16.27023\atlmfc\include\afxv_w32.h 40
Error C1083 Cannot open include file: 'atlimpl.cpp': No such file or directory DirClean c:\demo\dirclean\stdafx.cpp 34
the answer is: in my case: remove atlimp.h from stdafx.cpp file.
NeoKenshinX wrote: I'm migrating a VS 6.0 C++ project to VS 2010. The compiler tells me to remove following files:
statreg.cpp is obsolete. Please remove it from your project. atlimpl.cpp is obsolete. Please remove it from your project.
How can I remove these files (they are in the "External Dependencies" folder)?
They are #included in stdafx.cpp, if I recall correctly (or is it stdafx.h? ) And why is it necessary to remove them?
It's not necessary, but if you don't, you'll see this annoying warning every time you build. If you look at these files, they consist of nothing but #pragma message "statreg.cpp is obsolete. Please remove it from your project."
issue is:
Error C2316 'CMemoryException': cannot be caught as the destructor and/or copy constructor are inaccessible or deleted DirClean c:\demo\dirclean\cshellfileop.cpp 82
clipboard topics in VC. it will be used in my .NET version check project.
the first two articles are very useful and need to test their code and get good grasp on them.
time issues in Win32 MFC programming. one issue is:
Severity Code Description Project File Line Suppression State Error C2660 'ATL::CTime::GetLocalTm': function does not take 0 arguments Message5 c:\demo\message5\message5\message5.cpp 64
this post gives two ways to resolve the issue
