"Frank Richter" frank.richter@gmail.com wrote:
(Now using GradientFill() instead of GdiGradientFill().)
--- dlls/user/Makefile.in (/wine/trunk/dlls/user) (revision 21713) +++ dlls/user/Makefile.in (/me/trunk/dlls/user) (local) @@ -5,7 +5,7 @@ VPATH = @srcdir@ MODULE = user32.dll IMPORTLIB = libuser32.$(IMPLIBEXT) -IMPORTS = gdi32 advapi32 kernel32 ntdll +IMPORTS = gdi32 msimg32 advapi32 kernel32 ntdll
It's even worse. user32 can't depend on msimg32 or any other high level dll. Just add GdiGradientFill to wingdi.h and resend your 1st patch.
On 06.07.2005 16:44, Dmitry Timoshkov wrote:
It's even worse. user32 can't depend on msimg32 or any other high level
msimg32 is about as high-level as GDI itself... actually, it basically just forwards some functions to GDI. GradientFill() is nothing more than a forwarder to Gdi32.GdiGradientFill.
I'm a bit hesitant to add GdiGradientFill to wingdi.h as this function is practically undocumented, it doesn't appear on MSDN or the Platform SDK's wingdi.h.
-f.r.
"Frank Richter" frank.richter@gmail.com wrote:
msimg32 is about as high-level as GDI itself... actually, it basically just forwards some functions to GDI. GradientFill() is nothing more than a forwarder to Gdi32.GdiGradientFill.
I'm a bit hesitant to add GdiGradientFill to wingdi.h as this function is practically undocumented, it doesn't appear on MSDN or the Platform SDK's wingdi.h.
Well, if you inspect Wine headers (or better Wine source) close enough, you will find that it has a lot of undocumented things. There should not be any hesitation at all IMO in adding a prototype for already implemented API.
-
Dmitry Timoshkov -
Frank Richter