I have been working on, and almost have completed, rewriting Cpw (http://www.mathies.com/cpw) completely in D. However the requirements for certain windows header functions has cause me to come to a complete hault.

extern(Windows) ULONG* SetClassLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* SetWindowLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* GetClassLongPtrA(HWND, int);
extern(Windows) ULONG* GetWindowLongPtrA(HWND, int);

were all missing from all ports of the windows header files i could find. I was actually really dissapoined with the Core32 library (http://dsource.org/projects/core32/) as it had so many problems with it right off the svn server, i just gave up.

I got a good port (i think it's good) from DedicateD
(http://int19h.tamb.ru/files.html) which worked in all other ways, spare these
functions being missing.

I added the two Set... definitions into the windows.d file I got from DedicateD, which compiled fine (no undefined symbols anyways) but when I added the two Get... function definitions, I got undefined symbols. I am compiling the windows.d and winutil.d files as a lib, than including those files and linking the lib in another program, and that's where the errors come up. The lib compiles fine, no complaints.

Perhaps there is something I don't know about what's going on. PLEASE help me!

Another question... Why oh why does every port of the windows headers rename so many of the functions with an A at the end of the name?

ANY help is wanted and appriciated.

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal@hotmail.com

In article <d7bot7$226n$1@digitaldaemon.com>, Trevor Parscal says...
>
>I have been working on, and almost have completed, rewriting Cpw (http://www.mathies.com/cpw) completely in D. However the requirements for certain windows header functions has cause me to come to a complete hault.
>
>extern(Windows) ULONG* SetClassLongPtrA(HWND, int, ULONG*);
>extern(Windows) ULONG* SetWindowLongPtrA(HWND, int, ULONG*);
>extern(Windows) ULONG* GetClassLongPtrA(HWND, int);
>extern(Windows) ULONG* GetWindowLongPtrA(HWND, int);
>
>were all missing from all ports of the windows header files i could find. I was actually really dissapoined with the Core32 library (http://dsource.org/projects/core32/) as it had so many problems with it right off the svn server, i just gave up.
>
>I got a good port (i think it's good) from DedicateD
>(http://int19h.tamb.ru/files.html) which worked in all other ways, spare these
>functions being missing.
>
>I added the two Set... definitions into the windows.d file I got from DedicateD, which compiled fine (no undefined symbols anyways) but when I added the two Get... function definitions, I got undefined symbols. I am compiling the windows.d and winutil.d files as a lib, than including those files and linking the lib in another program, and that's where the errors come up. The lib compiles fine, no complaints.
>
>Perhaps there is something I don't know about what's going on. PLEASE help me!
>

You have to link with the appropriate library that contains these symbols, I guess user32.lib, but msdn says that there is no such function as SetClassLongPtr, there is without the ptr...

>Another question... Why oh why does every port of the windows headers rename so many of the functions with an A at the end of the name?
>

Because this is the original name of the functions. There are two versions for all win32 functions dealing with strings- one for ANSI and one for UNICODE. The ANSI one ends with A and UNICODE with W (I think from widechar). Win32 is hiding this with defines and stuff but if you look at the headers you will see...

>ANY help is wanted and appriciated.
>
>Thanks,
>Trevor Parscal
>www.trevorparscal.com
>trevorparscal@hotmail.com

On Sun, 29 May 2005 12:41:51 +0000 (UTC), bobef wrote:

> In article <d7bot7$226n$1@digitaldaemon.com>, Trevor Parscal says...
>>
>>I have been working on, and almost have completed, rewriting Cpw (http://www.mathies.com/cpw) completely in D. However the requirements for certain windows header functions has cause me to come to a complete hault.
>>
>>extern(Windows) ULONG* SetClassLongPtrA(HWND, int, ULONG*);
>>extern(Windows) ULONG* SetWindowLongPtrA(HWND, int, ULONG*);
>>extern(Windows) ULONG* GetClassLongPtrA(HWND, int);
>>extern(Windows) ULONG* GetWindowLongPtrA(HWND, int);
>>
>>were all missing from all ports of the windows header files i could find. I was actually really dissapoined with the Core32 library (http://dsource.org/projects/core32/) as it had so many problems with it right off the svn server, i just gave up.
>>
>>I got a good port (i think it's good) from DedicateD
>>(http://int19h.tamb.ru/files.html) which worked in all other ways, spare these
>>functions being missing.
>>
>>I added the two Set... definitions into the windows.d file I got from DedicateD, which compiled fine (no undefined symbols anyways) but when I added the two Get... function definitions, I got undefined symbols. I am compiling the windows.d and winutil.d files as a lib, than including those files and linking the lib in another program, and that's where the errors come up. The lib compiles fine, no complaints.
>>
>>Perhaps there is something I don't know about what's going on. PLEASE help me!
>>
> 
> You have to link with the appropriate library that contains these symbols, I guess user32.lib, but msdn says that there is no such function as SetClassLongPtr, there is without the ptr...
> 

Yes there is. I quote from the SDK docs ...

SetClassLongPtr Function

--------------------------------------------------------------------------------


The SetClassLongPtr function replaces the specified value at the specified offset in the extra class memory or the WNDCLASSEX structure for the class to which the specified window belongs.

This function supersedes the SetClassLong function. To write code that is compatible with both 32-bit and 64-bit Microsoft® Windows®, use SetClassLongPtr.


Syntax

ULONG_PTR SetClassLongPtr(          HWND hWnd,
    int nIndex,
    LONG_PTR dwNewLong
);
Parameters

hWnd
[in] Handle to the window and, indirectly, the class to which the window
belongs.
nIndex
[in] Specifies the value to replace. To set a value in the extra class
memory, specify the positive, zero-based byte offset of the value to be
set. Valid values are in the range zero through the number of bytes of
extra class memory, minus eight; for example, if you specified 24 or more
bytes of extra class memory, a value of 16 would be an index to the third
integer. To set a value other than the WNDCLASSEX structure, specify one of
the following values.
GCL_CBCLSEXTRA
Sets the size, in bytes, of the extra memory associated with the class.
Setting this value does not change the number of extra bytes already
allocated.
GCL_CBWNDEXTRA
Sets the size, in bytes, of the extra window memory associated with each
window in the class. Setting this value does not change the number of extra
bytes already allocated. For information on how to access this memory, see
SetWindowLongPtr.
GCLP_ HBRBACKGROUND
Replaces a handle to the background brush associated with the class.
GCLP_HCURSOR
Replaces a handle to the cursor associated with the class.
GCLP_HICON
Replaces a handle to the icon associated with the class.
GCLP_HICONSM
Retrieves a handle to the small icon associated with the class.
GCLP_HMODULE
Replaces a handle to the module that registered the class.
GCLP_MENUNAME
Replaces the pointer to the menu name string. The string identifies the
menu resource associated with the class.
GCL_STYLE
Replaces the window-class style bits.
GCLP_WNDPROC
Replaces the pointer to the window procedure associated with the class.
dwNewLong
[in] Specifies the replacement value.
Return Value

If the function succeeds, the return value is the previous value of the specified offset. If this was not previously set, the return value is zero.

If the function fails, the return value is zero. To get extended error information, call GetLastError.




Remarks

If you use the SetClassLongPtr function and the GCLP_WNDPROC index to replace the window procedure, the window procedure must conform to the guidelines specified in the description of the WindowProc callback function.

Calling SetClassLongPtr with the GCLP_WNDPROC index creates a subclass of the window class that affects all windows subsequently created with the class. An application can subclass a system class, but should not subclass a window class created by another process.

Reserve extra class memory by specifying a nonzero value in the cbClsExtra member of the WNDCLASSEX structure used with the RegisterClassEx function.

Use the SetClassLongPtr function with care. For example, it is possible to change the background color for a class by using SetClassLongPtr, but this change does not immediately repaint all windows belonging to the class.

Function Information

Header Declared in Winuser.h, include Windows.h
Import library User32.lib
Minimum operating systems Windows 95, Windows NT 3.1
Unicode Implemented as Unicode and ANSI versions on Windows NT, Windows
2000, Windows XP

See Also

Window Classes Overview, GetClassLongPtr, RegisterClassEx, SetWindowLongPtr, WindowProc, WNDCLASSEX

--------------------------------------------------------------------------------

© 2003 Microsoft Corporation. All rights reserved.
--------------------------------------------------------------------------------


-- 
Derek Parnell
Melbourne, Australia
29/05/2005 11:15:37 PM

>© 2003 Microsoft Corporation. All rights reserved.

:P:P

Just kidding :)

Anyway then just link with user32.lib. Just add it to the command line along with you .d sources. If it is supported in win95 it should work. I needed something like GradientFill and it wasn't there. I guess the library is at win95 level...

"Derek Parnell" <derek@psych.ward> wrote in message news:n8h30rzwkfg$.7luucwmdrm6s$.dlg@40tude.net...
> On Sun, 29 May 2005 12:41:51 +0000 (UTC), bobef wrote:
>
>> In article <d7bot7$226n$1@digitaldaemon.com>, Trevor Parscal says...
>>>
>>>I have been working on, and almost have completed, rewriting Cpw
>>>(http://www.mathies.com/cpw) completely in D. However the requirements
>>>for
>>>certain windows header functions has cause me to come to a complete
>>>hault.
>>>
>>>extern(Windows) ULONG* SetClassLongPtrA(HWND, int, ULONG*);
>>>extern(Windows) ULONG* SetWindowLongPtrA(HWND, int, ULONG*);
>>>extern(Windows) ULONG* GetClassLongPtrA(HWND, int);
>>>extern(Windows) ULONG* GetWindowLongPtrA(HWND, int);
>>>
>>>were all missing from all ports of the windows header files i could find.
>>>I was
>>>actually really dissapoined with the Core32 library
>>>(http://dsource.org/projects/core32/) as it had so many problems with it
>>>right
>>>off the svn server, i just gave up.
>>>
>>>I got a good port (i think it's good) from DedicateD
>>>(http://int19h.tamb.ru/files.html) which worked in all other ways, spare
>>>these
>>>functions being missing.
>>>
>>>I added the two Set... definitions into the windows.d file I got from
>>>DedicateD,
>>>which compiled fine (no undefined symbols anyways) but when I added the
>>>two
>>>Get... function definitions, I got undefined symbols. I am compiling the
>>>windows.d and winutil.d files as a lib, than including those files and
>>>linking
>>>the lib in another program, and that's where the errors come up. The lib
>>>compiles fine, no complaints.
>>>
>>>Perhaps there is something I don't know about what's going on. PLEASE help me!
>>>
>>
>> You have to link with the appropriate library that contains these
>> symbols, I
>> guess user32.lib, but msdn says that there is no such function as
>> SetClassLongPtr, there is without the ptr...
>>
>
> Yes there is. I quote from the SDK docs ...
>
> SetClassLongPtr Function
>
> --------------------------------------------------------------------------------
>
>
> The SetClassLongPtr function replaces the specified value at the specified offset in the extra class memory or the WNDCLASSEX structure for the class to which the specified window belongs.
>
> This function supersedes the SetClassLong function. To write code that is compatible with both 32-bit and 64-bit Microsoft® Windows®, use SetClassLongPtr.
>
>
> Syntax
>
> ULONG_PTR SetClassLongPtr(          HWND hWnd,
>    int nIndex,
>    LONG_PTR dwNewLong
> );

ULONG_PTR and LONG_PTR are typedefs for C's 'unsigned long' and 'long', respectively. "PTR" signifies a type big enough to hold a pointer, not a pointer itself. So, this would be the declaration in D:

    extern (Windows) :
    uint SetClassLongPtrA(HWND hWnd, int nIndex, int dwNewLong);
    uint SetClassLongPtrW(HWND hWnd, int nIndex, int dwNewLong);

Yes, both ANSI and Unicode versions are the same. The Unicode version is intended to be used when passing UTF16 strings. To avoid having to specify which version to call, use an alias:

    version (Unicode) {
        alias SetClassLongPtrW SetClassLongPtr;
    } else {
        alias SetClassLongPtrA SetClassLongPtr;
    }

Compile with:

    dmd -version=Unicode

I tend to dispense entirely with the ANSI API (on Windows 2000 and above, Unicode is native), so only declare the "W" versions, which obviates the need for the version attribute and compiler option.

> Parameters
>
> hWnd
> [in] Handle to the window and, indirectly, the class to which the window
> belongs.
> nIndex
> [in] Specifies the value to replace. To set a value in the extra class
> memory, specify the positive, zero-based byte offset of the value to be
> set. Valid values are in the range zero through the number of bytes of
> extra class memory, minus eight; for example, if you specified 24 or more
> bytes of extra class memory, a value of 16 would be an index to the third
> integer. To set a value other than the WNDCLASSEX structure, specify one
> of
> the following values.
> GCL_CBCLSEXTRA
> Sets the size, in bytes, of the extra memory associated with the class.
> Setting this value does not change the number of extra bytes already
> allocated.
> GCL_CBWNDEXTRA
> Sets the size, in bytes, of the extra window memory associated with each
> window in the class. Setting this value does not change the number of
> extra
> bytes already allocated. For information on how to access this memory, see
> SetWindowLongPtr.
> GCLP_ HBRBACKGROUND
> Replaces a handle to the background brush associated with the class.
> GCLP_HCURSOR
> Replaces a handle to the cursor associated with the class.
> GCLP_HICON
> Replaces a handle to the icon associated with the class.
> GCLP_HICONSM
> Retrieves a handle to the small icon associated with the class.
> GCLP_HMODULE
> Replaces a handle to the module that registered the class.
> GCLP_MENUNAME
> Replaces the pointer to the menu name string. The string identifies the
> menu resource associated with the class.
> GCL_STYLE
> Replaces the window-class style bits.
> GCLP_WNDPROC
> Replaces the pointer to the window procedure associated with the class.
> dwNewLong
> [in] Specifies the replacement value.
> Return Value
>
> If the function succeeds, the return value is the previous value of the specified offset. If this was not previously set, the return value is zero.
>
> If the function fails, the return value is zero. To get extended error information, call GetLastError.
>
>
>
>
> Remarks
>
> If you use the SetClassLongPtr function and the GCLP_WNDPROC index to replace the window procedure, the window procedure must conform to the guidelines specified in the description of the WindowProc callback function.
>
> Calling SetClassLongPtr with the GCLP_WNDPROC index creates a subclass of the window class that affects all windows subsequently created with the class. An application can subclass a system class, but should not subclass a window class created by another process.
>
> Reserve extra class memory by specifying a nonzero value in the cbClsExtra member of the WNDCLASSEX structure used with the RegisterClassEx function.
>
> Use the SetClassLongPtr function with care. For example, it is possible to change the background color for a class by using SetClassLongPtr, but this change does not immediately repaint all windows belonging to the class.
>
> Function Information
>
> Header Declared in Winuser.h, include Windows.h
> Import library User32.lib
> Minimum operating systems Windows 95, Windows NT 3.1
> Unicode Implemented as Unicode and ANSI versions on Windows NT, Windows
> 2000, Windows XP
>
> See Also
>
> Window Classes Overview, GetClassLongPtr, RegisterClassEx, SetWindowLongPtr, WindowProc, WNDCLASSEX
>
> --------------------------------------------------------------------------------
>
> © 2003 Microsoft Corporation. All rights reserved.
> --------------------------------------------------------------------------------
>
>
> -- 
> Derek Parnell
> Melbourne, Australia
> 29/05/2005 11:15:37 PM

John C, Derek Parnell,

Thank you, I will try your advice. Hopefully this library will really help the D comunity...

I named it Terra.

Thanks Again,
Trevor Parscal
www.trevorparscal.com
trevorparscal@hotmail.com

"Trevor Parscal" <Trevor_member@pathlink.com> wrote in message news:d7d4lo$3gl$1@digitaldaemon.com...
> John C, Derek Parnell,
>
> Thank you, I will try your advice. Hopefully this library will really help
> the D
> comunity...

I forgot to mention that the user32.lib file distributed with D is out of date and does not import the functions you wanted to use. So you'll need to create a .def file (call it 'user32ex.def') and run it through implib.

In 'user32ex.def':

    LIBRARY user32
    EXPORTS
    _SetClassLongPtrA@12 = SetClassLongPtrA
    _SetClassLongPtrW@12 = SetClassLongPtrW
    _SetWindowLongPtrA@12 = SetWindowLongPtrA
    _SetWindowLongPtrW@12 = SetWindowLongPtrW
    _GetClassLongPtrA@8 = GetClassLongPtrA
    _GetClassLongPtrW@8 = GetClassLongPtrW
    _GetWindowLongPtrA@8 = GetWindowLongPtrA
    _GetWindowLongPtrW@8 = GetWindowLongPtrW

Create an import library as follows:

    implib user32ex.lib user32ex.def

Finally add user32ex.lib to your list of lib files on the dmd command line.

>
> I named it Terra.
>
> Thanks Again,
> Trevor Parscal
> www.trevorparscal.com
> trevorparscal@hotmail.com

In article <d7d6u9$5kq$1@digitaldaemon.com>, John C says...
>
>I forgot to mention that the user32.lib file distributed with D is out of date and does not import the functions you wanted to use. So you'll need to create a .def file (call it 'user32ex.def') and run it through implib.
>
>In 'user32ex.def':
>
>    LIBRARY user32
>    EXPORTS
>    _SetClassLongPtrA@12 = SetClassLongPtrA
>    _SetClassLongPtrW@12 = SetClassLongPtrW
>    _SetWindowLongPtrA@12 = SetWindowLongPtrA
>    _SetWindowLongPtrW@12 = SetWindowLongPtrW
>    _GetClassLongPtrA@8 = GetClassLongPtrA
>    _GetClassLongPtrW@8 = GetClassLongPtrW
>    _GetWindowLongPtrA@8 = GetWindowLongPtrA
>    _GetWindowLongPtrW@8 = GetWindowLongPtrW
>
>Create an import library as follows:
>
>    implib user32ex.lib user32ex.def
>
>Finally add user32ex.lib to your list of lib files on the dmd command line.
>

It worked, but now, I have a GDIFlush Call, which is the same situation. It takes no arguments, so I thought it should be adeed to the user32ex.def as GDIFlush@0, as the error says it should be... But that's not working. Any ideas?

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal@hotmail.com

Please ignore my last post, I was naming it GDIFlush, instead of GdiFlush... stupid mistake.

The thing compiles fine now.

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal@hotmail.com

Well, I am now wondering what up with my windows version of user32.dll, cause it's got none of the functions I was needing...

extern(Windows) WINBOOL GdiFlush(VOID);
extern(Windows) ULONG* GetClassLongPtrA(HWND, int);
extern(Windows) ULONG* GetClassLongPtrW(HWND, int);
extern(Windows) ULONG* GetWindowLongPtrA(HWND, int);
extern(Windows) ULONG* GetWindowLongPtrW(HWND, int);

Are all apparently missing from my DLL..

the functions...

extern(Windows) ULONG* SetClassLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* SetClassLongPtrW(HWND, int, ULONG*);
extern(Windows) ULONG* SetWindowLongPtrA(HWND, int, ULONG*);
extern(Windows) ULONG* SetWindowLongPtrW(HWND, int, ULONG*);

Are in there, and mapped properly.

Any ideas as to what to do? Work arounds? I am stumped as to why a windows XP install wouldn't have these functions in the user32.dll library.

I really appriciate this help, it's making a big difference.

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal@hotmail.com