Printable View
I've just noticed an undocumented (by MSDN) Api called GdiGradientFill, it appears to be the same as the documented GradientFill except according to AllApi it's W2k+ only.
Does anyone know anything about it? Does it have any advantage over GradientFill?
Didn't realize it was there either. However, some quick googling shows that msimg32's GradientFill API simply calls gdi32's GdiGradientFill API. This appears founded looking at msimg32's decompiled GradientFill call:
Here's what I saw, looking at decompiled DLLs. Supports claim of Win2K+ only.Code:Disassembly of GradientFill (0x7638117F)
; Section: .text
;= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
; EXP: GradientFill (4)
; SYM:GradientFill
0x7638117F: 8BFF MOV EDI,EDI
0x76381181: 55 PUSH EBP
0x76381182: 8BEC MOV EBP,ESP
0x76381184: 5D POP EBP
0x76381185: FF2508203876 JMP DWORD PTR [0x76382008]
' ^^ the above shows that this function simply calls another function
0x7638118B: 90 NOP
0x7638118C: 90 NOP
0x7638118D: 90 NOP
0x7638118E: 90 NOP
0x7638118F: 90 NOP
1. Win2K,XP: GdiGradientFill exists; msimg32.DLL GradientFill redirected (above)
2. WinNT4: Non-existant. msimg32 not shipped with NT4, GDI32 has no reference to GdiGradientFill
3. Win98: GdiGradientFill does not exist; msimg32.DLL GradientFill has own code; does not jump to another function
WinME? Don't know; probably same as Win98
Edited: If you want to experiment, on Win2K+, delcare as follows:
Code:Private Declare Function GdiGradientFill Lib "gdi32" (... same parameters)
Just FYI: WinXP's msimg32 has only 5 exported functions, 3 of which are commonly known: AlphaBlend, GradientFill & TransparentBlt. All 3 jump to GDI32, each with a Gdi prefix: GdiAlphaBlend, GdiGradientFill, GdiTransparentBlt.
So the only advantage may be calling GDI32 directly on Win2K+ vs calling msimg32 which then jumps to gdi32, a few execution lines faster in memory. However, the disadvantage, obviously, is that you'd have to have multiple API declarations: Win2K+, Win98/ME.
Thankyou :)
I've been having some problems with GradientFill causing spectacular system crashes presumably because I've passed it bad vertex coords. If GdiGradientFill was a rewrite then it just might have been a bit more idiot (moi) friendly.
Well, have you looked at vbnet's example. Are you converting R/G/B values correctly?
http://vbnet.mvps.org/code/forms/gradientfill.htm
I'm pretty sure it's when I send out of range vertex coords as it works fine most of the time and the 48bit RGB values don't change where the coords do. It really is a spectacular crash; blank screen, internal speaker beep and restart making me reluctant to do too much detective work by purposefully trying to cause it.
I am using a slightly different vertex structure, but I don't think it's that. There are also around 10'000 little triangles but I don't think it's that either. The coords however are on rare occasions way out of DC bounds.
Code:Private Type tVertex
x As Long
y As Long
lRed As Byte
hRed As Byte
lGreen As Byte
hGreen As Byte
lBlue As Byte
hBlue As Byte
lAlpha As Byte
hAlpha As Byte
End Type
The structure shouldn't be an issue, both yours & the one on vbNet are 16bytes each.
Hmmm. Are you using AlphaBlend afterwards? If so, if the coords are outside of the bitmap dimensions, AlphaBlend will fail. I have seen AlphaBlend crash when not used properly. If AlphaBlend is in use, maybe rem that out for a test and see if crash persists.
But with the type of crash you are describing, the first thing I would absolutely ensure is that the amount of triangles and the pointer to to the first triangle matematically add up. In other words, if tVertex(0 to 5), and providing tVertex(3) as the pointer and saying you have 4 triangles can crash because API is looking for tVertex(3),(4),(5),(6). Spectacular crashes are usually writes to allocated system memory. I once crashed once so hard, I had to replace my Kernel32.dll; don't ask me how I did that -- I simply destroyed the project and moved on, as I was only playing around anyway.