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 [code]#define _WIN32_WINNT 0x0501[/code] to the stdafx.h helped.

[quote author=Hell-Lord link=topic=16934.msg171478#msg171478 date=1186732452]
#define WINVER 0x0500 should work perfectly fine.

Edit:

Done a search an apparently in some cases adding [code]#define _WIN32_WINNT 0x0501[/code] to the stdafx.h helped.
[/quote]
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.
[/quote]
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 author=brew link=topic=16934.msg171485#msg171485 date=1186761252]
I've tried that-- It throws a macro redefinition error.
[/quote]

[code]#ifdef _WIN32_WINNT
#undef _WIN32_WINNT
#endif
#define _WIN32_WINNT 0x0501[/code]

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)
[code]
g_OldWinProc = SetWindowLong(hWnd_txtChat, GWL_WNDPROC, EditBoxProc);
[/code]

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

[code]

WNDPROC editproc;

editproc = (WNDPROC)SetWindowLong(edithwnd, GWL_WNDPROC, (DWORD)WndProcEdit);

// ......
LRESULT CALLBACK WndProcEdit(HWND, UINT, WPARAM, LPARAM)
{

}

[/code]

[quote author=Yegg link=topic=16934.msg171494#msg171494 date=1186796627]
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.
[/quote]
I don't know if it's defined or not. My code works either way.

[quote author=l2k-Shadow link=topic=16934.msg171498#msg171498 date=1186806448]
lol.. don't blame functions for not working. :D

[code]

WNDPROC editproc;

editproc = (WNDPROC)SetWindowLong(edithwnd, GWL_WNDPROC, (DWORD)WndProcEdit);

// ......
LRESULT CALLBACK WndProcEdit(HWND, UINT, WPARAM, LPARAM)
{

}

[/code]
[/quote]
You're funny, shadow.
[code]
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

[/code][me=brew]giggles[/me]

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;
[/quote]

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 author=Kp link=topic=16934.msg171511#msg171511 date=1186855114]
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]
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 author=brew link=topic=16934.msg171514#msg171514 date=1186877550]
[quote author=Kp link=topic=16934.msg171511#msg171511 date=1186855114]
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]
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]

I'm sure had this been a more important problem you would of known this as well right? Right? Wrong.

[quote author=Kp link=topic=16934.msg171511#msg171511 date=1186855114]
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]
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 author=l)ragon link=topic=16934.msg171525#msg171525 date=1186908947]
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]

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.