i can not use CSplitbutton in MFC dialog based application it gives declaration error.
i include afxwin.h but giving same problem.
please help i am in deadlock.
Please enable Unicode setting in your project.
CSplitbutton has unicode dependency.
as given below
#if (_WIN32_WINNT >= 0x600) && defined(UNICODE)
class CSplitButton : public CButton
as per above code your version required vista + and enable unicode setting.
Related
I have the following code:
#define UNICODE
// so strange??
GetModuleBaseName( hProcess, hMod, szProcessName,
sizeof(szProcessName)/sizeof(TCHAR) );
But the compiler still report error like this:
error C2664: “DWORD K32GetModuleBaseNameA(HANDLE,HMODULE,LPSTR,DWORD)”: 无法将参数 3 从“wchar_t [260]”转换为“LPSTR” [E:\source\mh-gui\build\src\mhgui.vcxproj]
Which means cant convert param 3 from wchar_t[260] to LPSTR. It's look's like that still looking for A version api?
You must put
#define UNICODE
#define _UNICODE
BEFORE
#include <Windows.h>
The Windows header uses #ifdef UNICODE (et al), so if you want to make the distinction count, the #defines must occur before the #include.
edit: Because these #defines are functionally global, the most reliable place to add them is in your compiler options, so the ordering doesn't matter then.
Since you are using visual studio, instead of defining UNICODE yourself you should enable the W version by right clicking the project in the solution explorer -> properties -> Advanced -> Change the "Character Set" option to "Use Unicode Character Set"
I tried to compile TBB which I want to use on OpenCV. I am using Windows XP and Visual Studio 2010 C++. When I compiled TBB 4.4 I got the error
"The procedure entry point InitializeCriticalSectionEx could not be located in the dynamic link library KERNEL32.dll."
The error is similar but under little different conditions like here:
http://answers.opencv.org/question/6151/opencv_createsamplesexe-entry-point-problem-with-xp/
In my case I cannot run the program at all. I tried the solution described there, so I renamed InitializeCriticalSectionEx to InitializeCriticalSection and removed parameter 2 and 3.
OpenCV claimes the bug is not on their side. I know OpenCV uses this:
#if (_WIN32_WINNT >= 0x0600)
InitializeCriticalSectionEx(&cs, 1000, 0);
#else
InitializeCriticalSection(&cs);
#endif
I know this should not make any problems but I commented some lines to keep InitializeCriticalSection(&cs); only. I recompiled the OpenCV and still the same error. Finally I have found in TTB:
tbb44_20160627oss\include\tbb\machine\windows_api.h
__TBB_WINBASEAPI BOOL WINAPI TryEnterCriticalSection( LPCRITICAL_SECTION );
__TBB_WINBASEAPI BOOL WINAPI InitializeCriticalSectionAndSpinCount( LPCRITICAL_SECTION, DWORD );
// Overloading WINBASEAPI macro and using local functions missing in Windows XP/2003
#define InitializeCriticalSectionEx inlineInitializeCriticalSectionEx
I also find the word "InitializeCriticalSectionEx" in opencv_core310d.dll and opencv_core310.dll. Does the overload really work and why I got the error? How could I fix it?
Update:
the definition in OpenCV
#ifndef _WIN32_WINNT // This is needed for the declaration of TryEnterCriticalSection in winbase.h with Visual Studio 2005 (and older?)
#define _WIN32_WINNT 0x0400 // http://msdn.microsoft.com/en-us/library/ms686857(VS.85).aspx
#endif
"The procedure entry point InitializeCriticalSectionEx could not be located in the dynamic link library KERNEL32.dll."
This is a standard error that Windows displays when you try to run a program that contains a statically-bound call to a function in a DLL that does not exist.
The InitializeCriticalSectionEx function is not available on Windows XP, but the version of the library that you have contains code that calls this function.
OpenCV claimes the bug is not on their side. I know OpenCV uses this:
#if (_WIN32_WINNT >= 0x0600)
InitializeCriticalSectionEx(&cs, 1000, 0);
#else
InitializeCriticalSection(&cs);
#endif
OpenCV's workaround is a compile-time solution. It determines at the point when the library is compiled which version of Windows is being targeted, and uses that information to generate a call to the appropriate version of the function.
There are two possibilities for why this is going wrong in your case:
You are using the OpenCV library in binary form, and the binary that you have was compiled to target Windows Vista and later. You can solve this by obtaining the source code for OpenCV and compiling it yourself, either as a DLL or a static library.
You are compiling with _WIN32_WINNT set to 0x0600 or later. By default, the Windows headers define this symbol to the latest available version. You have to explicitly define an earlier target version if you want it. To arrange for targeting Windows XP, add the following code at the top of your code file (probably in your precompiled header):
#include <WinSDKVer.h>
#define _WIN32_WINNT _WIN32_WINNT_WINXP
#include <SDKDDKVer.h>
Porting my project from Qt4 to Qt5.1, I get this error from a Qt file:
C:\Qt\Qt5.1.1\5.1.1\mingw48_32\include\QtGui\qopenglversionfunctions.h:785: error: expected unqualified-id before ')' token
void (QOPENGLF_APIENTRYP MemoryBarrier)(GLbitfield barriers);
^
This is the chain of defines:
#define QOPENGLF_APIENTRYP QOPENGLF_APIENTRY *
#define QOPENGLF_APIENTRY APIENTRY
#define APIENTRY WINAPI
#define WINAPI __stdcall
I noticed that the "MemoryBarrier" token is present in the libQt5OpenGLExtensionsd.a library. Should I include it, even if in the original Qt4 project nothing related to OpenGL was used?
Platform:
Windows 7
MinGW 4.8
Qt 4.8 --> Qt 5.1
Besides the bug in MinGW 4.8.1 with uint64_t in io.h, there is also this one in QT 5.2.1 still. I came across this today when trying to compile QT 5.2.1 with MinGW 4.8.1, so I thought I would post my solution as well.
I don't know what the official fix will be for QT, but for my needs I did it like this:
in src/gui/opengl/qopengl.h line 49:
// Windows always needs this to ensure that APIENTRY gets defined
#if defined(Q_OS_WIN)
# include <QtCore/qt_windows.h>
#endif
I just undefined the windows MemoryBarrier macro there:
// Windows always needs this to ensure that APIENTRY gets defined
#if defined(Q_OS_WIN)
# include <QtCore/qt_windows.h>
# undef MemoryBarrier
#endif
I noticed that the "MemoryBarrier" token is present in the
libQt5OpenGLExtensionsd.a library. Should I include it, even if in the
original Qt4 project nothing related to OpenGL was used?
No, those are not related. OpenGLExtension is compiled after QtGui.
What you are hitting unfortunately is that there is a MemoryBarrier() already defined on Windows, and hence there is a clash for that and what qt is having. You can find the official Windows documentation for that:
http://msdn.microsoft.com/en-us/library/windows/apps/ms684208(v=vs.85).aspx
I have just discussed this with Gunnar, the QtGui maintainer, and I am planning to submit a change to Gerrit to address your issue.
We had used something like this in our project a couple of years ago when we were writing thread-safe singletons based on QtCore:
#if defined __GNUC__ && __GNUC__ >= 4 && __GNUC_MINOR__ >= 4
#define __MEMBARRIER __sync_synchronize();
#elif defined _MSC_VER && defined _WIN64
#define __MEMBARRIER MemoryBarrier();
#else
#define __MEMBARRIER
#endif
Qt may need to check ifdef MINGW/GCC/VERSION and undef the MemoryBarrier define.
EDIT: This was fixed about half a year ago. See the following Gerrit review and the corresponding bug report for details:
https://codereview.qt-project.org/#change,68156
and
https://bugreports.qt.io/browse/QTBUG-34080
So, update to Qt 5.2.0 and it will work. Failing that, you can try to backport it.
I run into the same problem. I could compile and run with just commenting out the problematic line:
// void (QOPENGLF_APIENTRYP MemoryBarrier)(GLbitfield barriers);
In file C:/Qt/Qt5.1.1/5.1.1/mingw48_32/include/QtGui/qopenglversionfunctions.h:785
My application does not use any OpenGL stuff. Let's hope they fix it soon ;-)
Since the accepted answer doesn't seem to help when one tries to build the QT library on it's own and Laszlo Pap claims that thie other solution is not a proper fix, I tried to find a way to fix it correctly. On Google I found a posting where it was said that MemoryBarrier is not implemented in MingW and there was a patch for it.
So I tried to incorporate the fix into opengl.h and hope that this is the correct way as simply commenting out the lines may cause problems later on.
#ifndef QT_NO_OPENGL
// Windows always needs this to ensure that APIENTRY gets defined
#if defined(Q_OS_WIN)
# include <QtCore/qt_windows.h>
#if defined(__MINGW32__) && defined(MemoryBarrier)
#undef MemoryBarrier
__CRT_INLINE void MemoryBarrier(void)
{
long Barrier = 0;
__asm__ __volatile__("xchgl %%eax,%0 "
:"=r" (Barrier));
}
#endif
#endif
I am trying to migrate existing c++ 32 code to 64 code on windows7 with visual studio 2010.i never did 64bit compilation before. with the help of internet references i did the setup for 64 bit compilation. like VS2010 with 64 bit compiler etc and other configuration changes.
In the preprocessor i removed WIN32 and added WIN64. i have some other pre-processors like OS_WIN_32 and some other which are specific in my code.
In the code wherever WIN32 was getting used i added extra condition as || WIN64 this is just to ensure that application should get compiled with win32 as well as win64.
When i am trying to compile the code i am getting the compilation error saying
fatal error C1189: #error : Only one of the WIN32 and WIN64 symbols should be defined
this error is coming from the local code where we have a check whether both WIN32 and WIN64 are defined. that code is as shown below.
#if defined WIN32 && defined WIN64
# error Only one of the WIN32 and WIN64 symbols should be defined
#endif
in VS2010 if macros are not enabled then the code inside the macro gets greyed out. in my code also the above error is greyed out. but still i am getting that error.
The code where i added WIN64 is including windows.h. for reference givine it below.
#if defined WIN32 || defined WIN64
#include <windows.h>
#include <process.h>
#endif
So my question is why i am getting this error? shouldnt we add windows.h for 64bit compilation.? i tried by commenting this inclusion but i am getting other errors wrt HANDLE which are used in the code.
If i go to WIN32 definition VS2010 is pointing to a definition in windef.h file. This file is present in Microsoft SDKs\windows\v7.0A\include folder i.e. not my local code.
for referance that definition is given below.
#ifndef WIN32
#define WIN32
#endif
So i want to know why compiler is getting both pre-processors WIN32 and WIN64.
Thanks in advance for your help.
You shouldn't define either yourself. The macro's that should be used to check this are
_WIN32 // always defined for Windows apps
_WIN64 // only defined for x64 compilation
These are defined by the compiler (see here).
Often, the IDE adds the unprefixed macros to the commandline to not let legacy projects which use the non-documented unprefixed versions fail to build. The fact that they work is not a reason to use them, when documented alternatives are present.
It boils down to this:
#ifdef _WIN32
// We're on Windows, yay!
#ifdef _WIN64
// We're on x64! Yay!
#else // _WIN64
// We're on x86 (or perhaps IA64, but that one doesn't matter anymore). Yay!
#endif // _WIN64
#else // _WIN32
// We're not on Windows, maybe WindowsCE or WindowsPhone stuff, otherwise some other platform
#endif
I'm compiling my application on a new box (vista 64) and now it doesn't compile anymore. The compiler gives me the error in the title. The problem seems(?) to be that HWINEVENTHOOK is defined twice in
windef.h
#if(WINVER >= 0x0400)
DECLARE_HANDLE(HWINEVENTHOOK);
#endif /* WINVER >= 0x0400 */
and then in winable.h it's
#if WINVER < 0x0500 // these structures and functions
// are in NT 5.00 and above winuser.h
typedef DWORD HWINEVENTHOOK;
However, I just looked up WINVER for vista and it is 0x0600 and windows XP is 0x0501 so why is DWORD being defined? I'm at a loss. Anyone help?
According to this MSDN forum thread:
winable.h was moved from the Windows
SDK in July 2005 because functionality
was duplicated in winuser.h. It was
determined at that time that efforts
would be better spent on updating
winuser.h to Windows Vista-level
functionality rather than updating the
functionality of both files.
What version of the Windows SDK are you using, and what Windows version is your code targetting? The target Windows version may be specified in a makefile, project file, or header file. Compiling your code on Vista doesn't necessarily mean that the target version is Vista.
Also, have you tried switching from winable.h to winuser.h?
You might need to explicitly set WINVER to the version corresponding to the minimum version of Windows you are targeting. I suspect its default value is not much above Win2K...
You could check its default value with a quick (untested) hack like this:
#include <windows.h>
#include <stdio.h>
int main(int argc, char **argv) {
printf("WINVER=0x%04x\n", WINVER);
return 0;
}
Compiled as a console app and run at the command prompt it might provide a clue. Otherwise, you'll spend ages chasing through include files trying to identify where it set the default.
Edit: In general, it is safest to always specify WINVER for a project. Either do it in the project settings in Visual Studio (and for all builds, not just the current build!) or do it in a common header file included by every module in the project. Doing so explicitly will reduce the chance that different build environment might have a different assumption.