[Solved] Shlwapi.dll, ColorRGBToHLS, Crash. ?

[MvGulik]

whatever Edited February 7, 2011 by MvGulik

[Yashied]

$aResult = DllCall($hDLL_Shlwapi, "none", "ColorRGBToHLS", "dword", $iColorRef, "dword*", 0, "dword*", 0, "dword*", 0)

$iH = $aResult[2]
$iL = $aResult[3]
$iS = $aResult[4]

[jchd]

Taken over by Yashied!

[MvGulik]

whatever Edited February 7, 2011 by MvGulik

[MvGulik]

whatever Edited February 7, 2011 by MvGulik

[jchd]

Your call only uses "word" types, not "word*".

Look at the MSDN page where they use "word*" for output. I'm not sure "dword*" would be correct.

Also I believe the way you setup $iColorRef isn't 100% correct: converting this way from floating-point gives a 64-bit integer:

Local $iColorRef = _GetColorValue($anRGB, True) ;; RGB to BGR

_DebugReportVar('$iColorRef', $iColorRef) ;### Debug DebugOut.

_DebugReportVar('hex($iColorRef)', hex($iColorRef)) ;### Debug DebugOut.

ConsoleWrite(VarGetType($iColorRef) & @LF) ; <<-- Int64

Passing it to DllCall with type "word" amounts to a cast, but I'd personally prefer a more explicit way to do so for my own code, just to be safe.

Maybe that's a nitpick.

Edited May 31, 2010 by jchd

[Yashied]

I'm not sure "dword*" would be correct.

It's does not matter, it's a pointer to the value of WORD type, or to the low-order word of DWORD type. This is the same.

ConsoleWrite(VarGetType(DllStructGetData(DllStructCreate('word'), 1)) & @CR)

Anyway, uses "Int32".

Edited May 31, 2010 by Yashied

[jchd]

Granted, that works on little-endian machines.

[MvGulik]

whatever Edited February 7, 2011 by MvGulik

[jchd]

AFAICS DllCall will cast the value to a word, as the type dictates. As I said, it was merely a nitpick, mostly due to the fact I frequently work with big-endian or bi-endian processors. Being repeatedly bitten between the legs by such mistakes in low-level code for 150K$ instruments makes you code more carefully at low-level (and wear titanium underwear).

[trancexx]

Why are you confusing people with VarGetType() function? Don't do that.

AutoIt works with variants and VarGetType will show you a type of variant holding the value that DllCall returned.

If DllCall() returns/requires word type then word is what you should be using. If it's pointer to word then it's word*. Nothing more to say there really.

Of course you can use dword*, or maybe uint64* or dword_ptr*, but why would you???

[Ascend4nt]

I agree with trancexx. There's no logical reason to use a datatype other than what is listed for an API call. It may work here because when the memory is allocated for a "dword*", you initialize it with 0. However, if you initialize it with something > 65535, things will fall apart.

Example:

$aResult = DllCall("shlwapi.dll", "none", "ColorRGBToHLS", "dword", $iColorRef, "dword*", 65536, "dword*", 65536, "dword*", 65536)
ConsoleWrite("Hue:"&$aResult[2]&", Lum:"&$aResult[3]&", Sat:"&$aResult[4]&@CRLF)

As you can see, the values returned are incorrect. The reason is the API call only writes a 16-bit value to the area pointed to. The upper 16-bits remain untouched.

You can change the above to "word*" and still keep 65536 there, and you'll actually get the correct return.

The point of all this is to use datatypes as they are defined. (especially with return and pointer types)

[MvGulik]

whatever Edited February 7, 2011 by MvGulik