I heard that I have to define WINVER as 0x0500 to use this. So i tried that, and it still errors with undeclared identifier. Does anyone have an updated user32.h?
#define WINVER 0x0500 should work perfectly fine.
Edit:
Done a search an apparently in some cases adding #define _WIN32_WINNT 0x0501 to the stdafx.h helped.
Quote from: Hell-Lord on August 10, 2007, 02:54 AM
#define WINVER 0x0500 should work perfectly fine.
Edit:
Done a search an apparently in some cases adding #define _WIN32_WINNT 0x0501 to the stdafx.h helped.
I've tried that--
Quote
NOTE: WINVER has been defined as 0x0500 or greater which enables
Windows NT 5.0 and Windows 98 features. When these headers were released,
Windows NT 5.0 beta 1 and Windows 98 beta 2.1 were the current versions.
For this release when WINVER is defined as 0x0500 or greater, you can only
build beta or test applications. To build a retail application,
set WINVER to 0x0400 or visit http://www.microsoft.com/msdn/sdk
to see if retail Windows NT 5.0 or Windows 98 headers are available.
See the SDK release notes for more information.
And I don't have StdAfx.h in my project at all.
What now? I tried downloading and installing the SDK, but it freezes when it is around 25% done. :/
Quote from: brew on August 10, 2007, 10:54 AM
I've tried that-- It throws a macro redefinition error.
#ifdef _WIN32_WINNT
#undef _WIN32_WINNT
#endif
#define _WIN32_WINNT 0x0501
Yoni, I'm curious, do you actually have to check if _WIN32_WINNT is already defined before undefining it? From the looks of it, a simple #undef _WIN32_WINNT works just fine.
Great. So I downloaded and installed the SDK, problem still not solved (at all). Now what? The actual .h files are oudated, they don't contain the prototype for SetLayeredWindowAttributes so on. Also SetWindowLongPtr isn't defined in my outdated .h files, which I need to use because SetWindowLong isn't working. Here's my code: (i'm trying to subclass a textbox)
g_OldWinProc = SetWindowLong(hWnd_txtChat, GWL_WNDPROC, EditBoxProc);
Just doesn't work.
error C2664: 'SetWindowLongA' : cannot convert parameter 3 from 'long (__stdcall *)(struct HWND__ *,unsigned int,unsigned int,long)' to 'long'
And if I try to cast it to LONG_PTR or DWORD_PTR, it says that's an undeclared identifier. help please :(
lol.. don't blame functions for not working. :D
WNDPROC editproc;
editproc = (WNDPROC)SetWindowLong(edithwnd, GWL_WNDPROC, (DWORD)WndProcEdit);
// ......
LRESULT CALLBACK WndProcEdit(HWND, UINT, WPARAM, LPARAM)
{
}
Quote from: Yegg on August 10, 2007, 08:43 PM
Yoni, I'm curious, do you actually have to check if _WIN32_WINNT is already defined before undefining it? From the looks of it, a simple #undef _WIN32_WINNT works just fine.
I don't know if it's defined or not. My code works either way.
Quote from: l2k-Shadow on August 10, 2007, 11:27 PM
lol.. don't blame functions for not working. :D
WNDPROC editproc;
editproc = (WNDPROC)SetWindowLong(edithwnd, GWL_WNDPROC, (DWORD)WndProcEdit);
// ......
LRESULT CALLBACK WndProcEdit(HWND, UINT, WPARAM, LPARAM)
{
}
You're funny, shadow.
g_OldWinProc = SetWindowLong(hWnd_txtChat, GWL_WNDPROC, (DWORD)EditBoxProc);
produces
error C2440: '=' : cannot convert from 'long' to 'long (__stdcall *)(struct HWND__ *,unsigned int,unsigned int,long)'
Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
/me giggles
yeah well if you're too dumb to even copy my code and cast SetWindowLong return to a WNDPROC then you shouldn't be programming.
yeah, i like how brew asks for help, or suggestions, and then when he receives some he cuts them down. the majority of the time, also, his cut downs are unwarranted because he can't even properly replicate code given to him.
So what, I didn't read your code well enough. How was I supposed to guess that I'm supposed to cast setwindowlong to a WNDPROC? Didn't even say that on MSDN. And why would i even need to do that..? IIRC SetWindowLong returns a 32 bit chunk of data, reguardless whether or not it's a pointer, it should still "fit" into the effing variable and compile. Thanks.
Also your response was very off-topic. I asked for a solution to my SetLayeredWindowAttributesWhatever api problem. A+ for effort, though.
Didn't say that on MSDN?
http://msdn2.microsoft.com/en-us/library/ms633570.aspx
and i quote from the above article:
Quote
// Subclass the edit control.
wpOrigEditProc = (WNDPROC) SetWindowLong(hwndEdit,
GWL_WNDPROC, (LONG) EditSubclassProc);
//
// Continue the initialization procedure.
//
return TRUE;
also you mentioned that what you were attempting to do is subclass an edit control. Don't ask for help if you don't wish to receive it.
Yes, the result of SetWindowLong will fit into the variable, but you are storing it into a variable of a different type than SetWindowLong returns. The compiler is trying to keep you from making a mistake by refusing to silently change the type. In this case, the programmer can recognize that he wants to store the result anyway, and override the compiler with a simple typecast.
Also, your code is badly outdated. You are calling the ANSI version of the function, and you are using SetWindowLong (which takes a LONG (always 32 bits)) when you are using a pointer (may not always be 32 bits). Your code will break on Win64.
Quote from: Kp on August 11, 2007, 12:58 PM
Also, your code is badly outdated. You are calling the ANSI version of the function, and you are using SetWindowLong (which takes a LONG (always 32 bits)) when you are using a pointer (may not always be 32 bits). Your code will break on Win64.
I don't intend my code to ever be run on a win64 platform. If someone does run it, and it breaks, then OH WELL, thats their own fault. Not like my battle.net chatterbot is going to be the next firefox or something.
Quote from: brew on August 11, 2007, 07:12 PM
Quote from: Kp on August 11, 2007, 12:58 PM
Also, your code is badly outdated. You are calling the ANSI version of the function, and you are using SetWindowLong (which takes a LONG (always 32 bits)) when you are using a pointer (may not always be 32 bits). Your code will break on Win64.
I don't intend my code to ever be run on a win64 platform. If someone does run it, and it breaks, then OH WELL, thats their own fault. Not like my battle.net chatterbot is going to be the next firefox or something.
I'm sure had this been a more important problem you would of known this as well right? Right? Wrong.
Quote from: Kp on August 11, 2007, 12:58 PM
Yes, the result of SetWindowLong will fit into the variable, but you are storing it into a variable of a different type than SetWindowLong returns. The compiler is trying to keep you from making a mistake by refusing to silently change the type. In this case, the programmer can recognize that he wants to store the result anyway, and override the compiler with a simple typecast.
Also, your code is badly outdated. You are calling the ANSI version of the function, and you are using SetWindowLong (which takes a LONG (always 32 bits)) when you are using a pointer (may not always be 32 bits). Your code will break on Win64.
Thought that the 64bit versions of windows had the backward compatability mode for people who were, or are to ignorant to conform to the 64bit systems?
Quote from: l)ragon on August 12, 2007, 03:55 AM
Thought that the 64bit versions of windows had the backward compatability mode for people who were, or are to ignorant to conform to the 64bit systems?
Yes, that is true. However, there are some things which work differently or do not work when you are running in compatibility mode. Therefore, all new programs should be written in such a way that they can be compiled for native 64bit mode, rather than relying on the compatibility layer.