WinGetTrans by Valik

[Info]

I found this function:

Func WinGetTrans($sTitle, $sText = "")
    Local $hWnd = WinGetHandle($sTitle, $sText)
    If Not $hWnd Then Return -1
    Local $aRet = DllCall("user32.dll", "int", "GetLayeredWindowAttributes", "hwnd", $hWnd, "ptr", 0, "int_ptr", 0, "ptr", 0)
    If @error Or Not $aRet[0] Then Return -1
    Return $aRet[3]
EndFunc

and used it:

$wgt = WinGetTitle("")
WinSetTrans($wgt,"",100)
MsgBox(0,"",WinGetTrans($wgt))
WinSetTrans($wgt,"",255)

Func WinGetTrans($sTitle, $sText = "")
    Local $hWnd = WinGetHandle($sTitle, $sText)
    If Not $hWnd Then Return -1
    Local $aRet = DllCall("user32.dll", "int", "GetLayeredWindowAttributes", "hwnd", $hWnd, "ptr", 0, "int_ptr", 0, "ptr", 0)
    If @error Or Not $aRet[0] Then Return -1
    Return $aRet[3]
EndFunc

and WinGetTrans returns 0 to me...

What am I doing wrong?

[trancexx]

Replace "int_ptr" with "ubyte*"

[Melba23]

Info,

A bit of searching found this updated version which works for me on Vista:

$wgt = WinGetTitle("")
WinSetTrans($wgt,"",100)
Sleep(10)
MsgBox(0,"",WinGetTrans($wgt))
WinSetTrans($wgt,"",255)

Func WinGetTrans($sTitle, $sText = "")
    Local $hWnd = WinGetHandle($sTitle, $sText)
    If Not $hWnd Then Return -1
    Local $val = DllStructCreate("int")
    Local $aRet = DllCall("user32.dll", "int", "GetLayeredWindowAttributes", "hwnd", $hWnd, "ulong_ptr", 0, "int_ptr", DllStructGetPtr($val), "ulong_ptr", 0)
    If @error Or Not $aRet[0] Then Return -1
    Return DllStructGetData($val, 1)
EndFunc

M23

[Info]

Thanks

[Inverted]

The original didn't work just like that because :

  Quote

GetLayeredWindowAttributes can be called only if the application has previously called SetLayeredWindowAttributes on the window.

@ trancexx

No, that parameter is a pointer to a byte, not a byte itself. So int_ptr looks correct.

Edited October 17, 2009 by Inverted

[monoceres]

  On 10/17/2009 at 3:28 PM, 'Inverted said:

@ trancexx

No, that parameter is a pointer to a byte, not a byte itself. So int_ptr looks correct.

trancexx is more than correct, take a look at the msdn page.

http://msdn.microsoft.com/en-us/library/ms633508%28VS.85%29.aspx

Edited October 17, 2009 by monoceres

[Inverted]

That's what I'm looking at. And it says it's a "Pointer to a byte"

Also, Melba23 posted a working example. And he uses int_ptr.

Edited October 17, 2009 by Inverted

[monoceres]

  On 10/17/2009 at 3:42 PM, 'Inverted said:

That's what I'm looking at. And it says it's a "Pointer to a byte"

Also, Melba23 posted a working example. And he uses int_ptr.

Ok here's why the example works, but is still incorrect.

First of BYTE is typedef'd to unsigned char, so we can all agree that's 'byte' in autoit.

So how do you create a pointer to a byte in autoit?

You can either create a struct containing a byte and use dllstructgetptr on it, however in this case this is overwork since you can just specify ubyte* and autoit will create an unsigned char internally and pass the pointer to it.

What Melba23 did was to create an int in a struct and pass the pointer to that int (that would be equal to passing int* in the dllcall). This works because:

a ) Pointers to chars and int's are pretty much the same. At at least when just casting between them.

b ) Windows expects a unsigned char but gets an int, does this matter? No, since windows just assumes it's an char and uses it anyway (it doesn't crash because an int is larger than a char).

Edited October 17, 2009 by monoceres

[Melba23]

Hi all,

Before anyone gets a over-inflated idea of my DLL-calling abilities and starts asking for my opinion, I merely posted an example I found on the forums which worked when I tried it.

I have enjoyed the discussion though!

M23

[Inverted]

Hmm, that makes sense, I will reread it later. High level languages confuse me sometimes. I assumed that if you passed a wrong size variable as a parameter you'd crash after the return

But I understand that AutoIt's Byte is different

[monoceres]

  On 10/17/2009 at 3:57 PM, 'Inverted said:

Hmm, that makes sense, I will reread it later. High level languages confuse me sometimes. I assumed that if you passed a wrong size variable as a parameter you'd crash after the return

But I understand that AutoIt's Byte is different

This is more low-level than high.

And yes, when using the stdcall calling convention (standard in autoit) the callee is responsible for cleaning the stack so wrong parameter size leads to stack corruption. However we did not pass parameters of wrong size, we passed a pointer to an int (4 bytes) instead of a pointer to a char (also 4 bytes) so that's not a problem. What the pointers point to doesn't matter as long as the data they point to is valid.

[trancexx]

AutoIt makes life easier. Lot of the job is done internally.

Pointer is a pointer. See this:

ConsoleWrite("! " & _Chr(65) & _Chr(110) & _Chr(32) & _Chr(101) & _Chr(120) & _Chr(99) & _Chr(101) & _Chr(115) & _Chr(115) & _Chr(32) & _Chr(111) & _Chr(102) & _Chr(32) & _Chr(119) & _Chr(104) & _Chr(97) & _Chr(116) & _Chr(32) & _Chr(105) & _Chr(115) & _Chr(32) & _Chr(110) & _Chr(101) & _Chr(99) & _Chr(101) & _Chr(115) & _Chr(115) & _Chr(97) & _Chr(114) & _Chr(121) & _Chr(46) & @CRLF )


Func _Chr($iASCII)

    Local $hWnd = GUICreate("")

    WinSetTrans($hWnd, 0, $iASCII)

    Local $aCall = DllCall("user32.dll", "int", "GetLayeredWindowAttributes", "hwnd", $hWnd, "dword*", 0, "str", "", "dword*", 0)

    If @error Or Not $aCall[0] Then
        GUIDelete()
        Return ""
    EndIf

    GUIDelete()

    Return $aCall[3]

EndFunc

How do you call that?