www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Windows Header Files!

reply Trevor Parscal <Trevor_member pathlink.com> writes:
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
May 28 2005
next sibling parent reply bobef <bobef_member pathlink.com> writes:
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
May 29 2005
parent reply Derek Parnell <derek psych.ward> writes:
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
May 29 2005
next sibling parent bobef <bobef_member pathlink.com> writes:
© 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...
May 29 2005
prev sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"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
May 29 2005
parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
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
May 29 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
"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
May 29 2005
parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
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
May 29 2005
next sibling parent Trevor Parscal <Trevor_member pathlink.com> writes:
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
May 29 2005
prev sibling parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
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
May 29 2005
parent "John C" <johnch_atms hotmail.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message 
news:d7dctv$b2o$1 digitaldaemon.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);


GdiFlush is in gdi32.dll. Link in gdi32.lib.


 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..


Ok, it appears these functions don't exist for 32-bit Windows (64-bit only). 
I've tracked them down in the SDK headers, and they're just aliases for 
GetWindowLong etc. The equivalent in D is to do this:

    alias GetWindowLongA GetWindowLongPtrA;
    alias GetClassLongA GetClassLongPtrA;

and so on.

They're included for symmetry with the Set*LongPtr functions, which do 
exist.

Also, as I mentioned earlier, they don't return pointers - LONG_PTR is a 
typedef for C's 'long', which is the same as 'int' in D.


 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
May 29 2005
prev sibling parent reply J C Calvarese<technocrat7 gmail.com> writes:
In article <d7bot7$226n$1 digitaldaemon.com>, Trevor Parscal says...

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.


Care to tell me what the problems are so that I might be able to fix them?

I just realized that the links in
http://www.dsource.org/forums/viewforum.php?f=16 were messed up from the some
changes that happened recently with the dsource upgrade. I'm sorry if that
wasted your time. It's fixed now.

jcc7
May 29 2005
parent reply bobef <bobef_member pathlink.com> writes:
In article <d7dd49$bac$1 digitaldaemon.com>, J C Calvarese says...

In article <d7bot7$226n$1 digitaldaemon.com>, Trevor Parscal says...

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.


Care to tell me what the problems are so that I might be able to fix them?


I can tell you few things I met...

First I wanted to have IE in my app and it was OK althought to get a single
window I need kilobytes of code but there was no interface (or whatever it is
called) for the events so it is useless to me...

Most common controls are missing.

GradientFill is missing.

And the other thing I had problem with was to discover which module contains the
functions I need. Maybe naming it like MS would help... then you can just look
in msdn amd import core32.windows; or whatever...

It is nice project and I can see you've done a LOT of work. But wouldn't it be
wiser to extend http://int19h.tamb.ru 's headers instead of rewriting all
that...
May 29 2005
parent reply J C Calvarese<technocrat7 gmail.com> writes:
In article <d7de8s$c8i$1 digitaldaemon.com>, bobef says...

In article <d7dd49$bac$1 digitaldaemon.com>, J C Calvarese says...

In article <d7bot7$226n$1 digitaldaemon.com>, Trevor Parscal says...

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.


Care to tell me what the problems are so that I might be able to fix them?


I can tell you few things I met...


Thanks for your input.


First I wanted to have IE in my app and it was OK althought to get a single
window I need kilobytes of code but there was no interface (or whatever it is
called) for the events so it is useless to me...

Most common controls are missing.


So you're saying that commctrl.d is incomplete. I believe you, but I'm just one
person and it's tricky figuring out what is particular needs to be added. I
would accepted donated code if it fit with the Core32 style (which is hard to
describe). ;)


GradientFill is missing.


I guess it is missing. According to MSDN, it's been around for a while so I
can't explain why it's not there. It should be part of wingdi.d.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_8oa4.asp

Maybe Core32 is based on a really old version of the Platform SDK. That'd be bad
news. :(


And the other thing I had problem with was to discover which module contains 
 the functions I need. Maybe naming it like MS would help... then you can just
> look in msdn amd import core32.windows; or whatever...


I think "import win32.api" was meant to fill this role, but now that I look at
it not everything is imported. Hmmm...


It is nice project and I can see you've done a LOT of work. 


Actually, Mike Wynn did most of the work. I've just tried to keep it going when
he apparently dropped the project.


But wouldn't it be wiser to extend http://int19h.tamb.ru 's headers instead of
>rewriting all that...


I've been aware of int19h.tamb.ru for years, but it hasn't been updated in a
long time. If I were to approach the project from a new angle (and redo
everything), I'd base it on the public domain headers (w32api) from
http://www.mingw.org/ (and rely heavily on automation).

If anyone has another other specific complaints and comments about Core32, we
should probably discuss them over at the forum at dsource
(http://www.dsource.org/forums/viewforum.php?f=16), so that we don't clutter up
this newsgroup.

jcc7
May 29 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
GradientFill is missing.


 I guess it is missing. According to MSDN, it's been around for a while so 
 I
 can't explain why it's not there. It should be part of wingdi.d.
 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_8oa4.asp


GradientFill  resides in Msimg32.dll.

Msimg32 appeared in WinME - there it is
a full implementation.

Msimg32.dll on XP is a proxy
for correspondent GdiGradientFill, etc.
calls from GDI32.dll.

Ideally your application should not
depend on Msimg32.dll existence so
you cannot link it statically.

Andrew.
May 29 2005