I am currently using Graphics, Image, Color, and Bitmap Gdi+ classes in my C++ Application, but whenever I try to use BrightnessContrast and BrightnessContrastParams I get errors:
In Intellisense: Error: Namespace 'Gdiplus' has no member 'BrightnessContrast'
When Compiling: 'BrightnessContrast' : is not a member of 'Gdiplus'
What gives? I did find a forum post that said to add a line to "Additional Manifest Dependencies:" in the project properties, I did this but it still didn't work. The post goes on to say try looking in %windir%\winsxs if that doesn't work but I don't see how to make sense of the files in that directory. I am using VisualStudio 2010 on Windows7 64bit.
Also, I am aware that I can create my own Brightness and Contrast functions. I am wondering why I can't use the build-in Classes that are documented on MSDN.
Thanks
These members are only available in GDI+ version 1.10, the version that shipped first with Vista. You have to explicitly opt-in to use them. Like this:
#define GDIPVER 0x110
#include <gdiplus.h>
Beware that your program won't run on XP when you do this.
Related
I have exactly the opposite problem to VSCode turn of _WIN32 define - Visual Studio Code is failing to define _WIN32 for me. This is in a cross-platform project that is being developed on Windows with the Microsoft compiler, but needs to also be able to compile on Linux, so I have
#ifdef _WIN32
#include <windows.h>
failing, and VS Code then marks all references to Windows API types etc. with red underlines. (The include mechanism itself is working fine, e.g. it has no problem including regular C++ headers.)
Is there any known reason why VS Code on Windows might fail to define _WIN32? The question I linked suggests it should, and I haven't knowingly changed any settings related to it.
Most likely, the problem is VSCode is using the wrong C++ compiler to gather the predefined macros, and that compiler does not predefine _WIN32.
To check, in Command Palette (Ctrl+Shift+P), run "C/C++: Log Diagnostics". The output will show you which compiler VSCode found and what it detected as its built-in include path and preprocessor defines. If my guess is correct, the diagnostics will show the wrong compiler being used, and _WIN32 missing.
Assuming so, to solve this, use the command Palette to run "C/C++: Edit Configurations (UI)", then set "Compiler path" to point at your compiler executable (cl.exe in this case). That should solve the problem because VSCode will then query that compiler to determine the predefined macros, which will include _WIN32. Re-run the diagnostics to confirm.
(I just gave a similar answer to the question linked to in the question above, as I think both questions have essentially the same problem and solution, just with different details.)
I have a header file with the following code:
Microsoft::WRL:ComPtr<ID3D11Device2> m_device;
inside a class definition. Visual Studio 2013 is saying that Microsoft is not a namespace, if I take the code and cut it out and put it in another class in another file unchanged it works just fine!
Any ideas?
Philip
EDIT: All of a sudden (without me having changed anything) Intelissense now accepts Microsoft::WRL::ComPtry as valid but when I compile it still gives me errors that it does not exists.
You need to
#include <wrl.h>
or
#include <wrl/client.h>
To get Microsoft::WRL::ComPtr in your module.
When you say "Visual Studio 2013 is saying that Microsoft is not a namespace" do you mean you get a compiler error or is just Intellisense? When dealing with headers, Intellisense can get a bit out of sync until you build again. For example:
//Test.h
class A { Microsoft::WRL::ComPtr<T> a; };
//Test.cpp
#include <wrl/client.h>
#include "Test.h"
If you just added the #include <wrl/client.h> to the Test.cpp, Intellisense might not know yet it is in scope for the header. It's perfectly valid C++ already, but a better practice is to include in your headers the ones it needs like:
//Test.h
#pragma once
#include <wrl/client.h>
class A { Microsoft::WRL::ComPtr<T> a; };
The other way this sync issue can manifest itself is if you are doing:
//Test.h
class A { Microsoft::WRL::ComPtr<T> a; };
//Test.cpp
#include "pch.h"
#include "Test.h"
//pch.h
#include <wrl/client.h>
Again, fully valid C++ that will build. Intellisense knows it works when you build, but might not until then.
Note: WRL is traditional C++ and is not using C++/CX language extensions. They both exist to make it easier to consume WinRT APIs from C++, and you will see the Microsoft::WRL::ComPtr used inside C++/CX applications when dealing with non-WinRT COM APIs like Direct3D. And you can mix C++/CX with WRL in the same application taking advantage of the fact that you can use reinterpret_cast<> between C++/CX ref ^ and ABI COM pointers. You can use Microsoft::WRL::ComPtr in old-school Windows desktop apps on Windows 7 or Windows Vista too.
With all that said, WRL and C++/CX are two distinct things.
Update: For consuming Windows Runtime APIs, you can also use C++/WinRT which is also 'standard' C++ without any need for the C++/CX extensions. See Microsoft Docs. You can use Microsoft::WRL::ComPtr for C++/WinRT applications, or you can use their variant wrl::com_ptr
I am trying to run the Microsoft DirectComposition Sample which utilizes various IDComposition_____ types. It appears that I am missing dcomp.h which contains these types. I've tried looking around for the header file, but can't seem to find it anywhere.
Am I going about this the wrong way or something?
Maybe someone can point a link towards dcomp.h..?
This is part of the Windows SDK for Windows 8. It’s included with Visual Studio 2012. For other compilers you’ll need to download the SDK separately.
http://msdn.microsoft.com/en-us/windows/desktop/hh852363.aspx
Is it possible to compile libexif with Visual Studio 2010? I have been trying to do so and have been running into a whole slew of problems. I cannot find any information about whether anybody has successfully done this before. I know I can use MinGW to compile the library, but I am in a situation where I need it to be compiled with Visual Studio and then need to link to it from a Visual C++ app. Is this possible?
To answer your question: Yes it is possible... but it is a bit of a hack. Libexif uses functions that MSVC has chosen not to implement. See my working example VS2010 project below (if you don't like downloading files then skip to my explanation of what needed changing to get it to work below):
https://www.dropbox.com/s/l6wowl8pouux01a/libexif-0.6.21_CompiledInVS2010%2BExample.7z?dl=0
To elaborate, the issues that needed a "hack" (as hinted in the LibExif readme-win32.txt documentation) are:
Libexif uses inline in several places which is not defined in VS for C, only C++ (see this)
Libexif uses snprintf extensively in the code which is not defined in VS (see here)
You need to create the config.h yourself without a ./configure command to help you. You could read through the script but most of it doesn't make sense for Windows VS2010.
You will need to define GETTEXT_PACKAGE because it's probably setup in the configure file. I just choose UTF-8, whether that is correct or not I'm not sure.
There was a random unsigned static * that needed to be moved from a .c file to the .h file as C in VS doesn't allow you to create new variables inside functions in the particular way they were trying to do.
Read the "readme-win32.txt" file. Advice is:
hack yourself a build system somehow. This seems to be the Windows way of doing things.
Don't get your hopes up. The *nix way of doing things is the configuration script that needs to be run first. It auto-generates source files to marry the library to the specific flavor of *nix. The configuration script is almost half a megabyte. Three times as much code as in the actual .c files :) You cannot reasonably get that working without MinGW so you can execute the script. Once you got that done, you've got a better shot at it with a VS solution. As long as it doesn't use too much C99 specific syntax.
At the moment CUDA already recognizes a key CUDA C/C++ function such as cudaMalloc, cudaFree, cudaEventCreate, etc.
It also recognizes certain types like dim3 and cudaEvent_t.
However, it doesn't recognize other functions and types such as the texture template, the __syncthreads functions, or the atomicCAS function.
Everything compiles just fine, but I'm tired of seeing red underlinings all over the place and I want to the see the example parameters displayed when you type in any recognizable function.
How do I get VS to catch these functions?
You could create a dummy #include file of the following form:
#pragma once
#ifdef __INTELLISENSE__
void __syncthreads();
...
#endif
This should hide the fake prototypes from the CUDA and Visual C++ compilers, but still make them visible to IntelliSense.
Source for __INTELLISENSE__ macro: http://blogs.msdn.com/b/vcblog/archive/2011/03/29/10146895.aspx
You need to add CUDA-specific keywords like __syncthreads to the usertype.dat file for visual studio. An example usertype.dat file is included with the NVIDIA CUDA SDK. You also need to make sure that visual studio recognizes .cu files as c/c++ files as described in this post:
Note however that where that post uses $(CUDA_INC_PATH), with recent versions of CUDA you should use $(CUDA_PATH)/include.
Also, I would recommend Visual Assist X -- not free, but worth the money -- to improve intellisense. It works well with CUDA if you follow these instructions:
http://www.wholetomato.com/forum/topic.asp?TOPIC_ID=5481
http://forums.nvidia.com/index.php?showtopic=53690