Sign in to follow this  
Followers 0
Info

WinGetTrans by Valik

12 posts in this topic

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?

Share this post


Link to post
Share on other sites



Replace "int_ptr" with "ubyte*"


♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

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


Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind._______My UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Share this post


Link to post
Share on other sites

#5 ·  Posted (edited)

The original didn't work just like that because :

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 by Inverted

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

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 by Inverted

Share this post


Link to post
Share on other sites

#8 ·  Posted (edited)

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 by monoceres

Broken link? PM me and I'll send you the file!

Share this post


Link to post
Share on other sites

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


Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind._______My UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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.


Broken link? PM me and I'll send you the file!

Share this post


Link to post
Share on other sites

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?


♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0