Sign in to follow this  
Followers 0
-Ultima-

Transparency issue with icon controls on tabs...

11 posts in this topic

#1 ·  Posted (edited)

If you create an icon control on top of a tab control, then move the window off the left side of the screen and then back on screen, AutoIt seems to forget that the background is supposed to be transparent. In AutoIt v3.2.10.0, the background turns white. In AutoIt v3.2.11.x, the background turns black. Here's an example script that demonstrates the behavior:

Global $winWidth = 256, $winHeight = 256

Global $hGUI = GUICreate(@AutoItVersion, $winWidth, $winHeight, 0)
GUICtrlCreateTab(5, 5, $winWidth - 10, $winHeight - 10)
GUICtrlCreateTabItem("Tab")
GUICtrlCreateIcon("shell32.dll", -5, ($winWidth-128)/2, ($winHeight-128)/2, 128, 128)
GUICtrlCreateTabItem("")

GUISetState()

Global $aiPos = WinGetPos($hGUI)
Do
    winHMove(-1)
Until $aiPos[0] <= -$winWidth

Do
    winHMove(1)
Until $aiPos[0] >= 0

Do
Until GUIGetMsg() = -3

Func winHMove($iOffset)
    WinMove($hGUI, "", $aiPos[0] + $iOffset, $aiPos[1])
    Sleep(1)
    $aiPos = WinGetPos($hGUI)
EndFunc

Also worth noting is the fact that the problem isn't exclusively a problem with the left-hand side of the screen. It seems like it's the fact that the top-left corner of the icon control isn't actually visible while the control is moving (relatively) right-ward while getting "unhidden" that causes this to happen. Another way to demonstrate the problem would be to cover the control completely with another window, then move the covering window left-ward (so that the icon control is moving right-ward relative to the window). You'll see the issue occur here as well.

Basically, it looks like a repainting issue. If the tab control is removed, the problem no longer occurs. I've tried using WM_PAINT to manually redraw the icon control using RedrawWindow, but the background doesn't go away until the control is fully visible (which is slightly less than helpful -- I don't want to see the non-transparent background at all). What I'm wondering is... is there any way to prevent this from happening?

Edited by -Ultima-

[ WinINet.au3 | Array.au3 (Optimized) | _UnixTimeParse() ]

Share this post


Link to post
Share on other sites



Awesome ! :(

Nice magic trick.. and I'm amazed you could discover such a particular bug. However no clue about the answer :)

Share this post


Link to post
Share on other sites

Heh, wasn't meant to be a magic trick :) I noticed the bug because I happen to use icon controls on my tab controls, and this kind of behavior quickly becomes very obvious when you simply move the window around, or other windows around it.

After a bit of tinkering around, I still can't figure this out :/


[ WinINet.au3 | Array.au3 (Optimized) | _UnixTimeParse() ]

Share this post


Link to post
Share on other sites

If you create an icon control on top of a tab control, then move the window off the left side of the screen and then back on screen, AutoIt seems to forget that the background is supposed to be transparent. In AutoIt v3.2.10.0, the background turns white. In AutoIt v3.2.11.x, the background turns black. Here's an example script that demonstrates the behavior:

Global $winWidth = 256, $winHeight = 256

Global $hGUI = GUICreate(@AutoItVersion, $winWidth, $winHeight, 0)
GUICtrlCreateTab(5, 5, $winWidth - 10, $winHeight - 10)
GUICtrlCreateTabItem("Tab")
GUICtrlCreateIcon("shell32.dll", -5, ($winWidth-128)/2, ($winHeight-128)/2, 128, 128)
GUICtrlCreateTabItem("")

GUISetState()

Global $aiPos = WinGetPos($hGUI)
Do
    winHMove(-1)
Until $aiPos[0] <= -$winWidth

Do
    winHMove(1)
Until $aiPos[0] >= 0

Do
Until GUIGetMsg() = -3

Func winHMove($iOffset)
    WinMove($hGUI, "", $aiPos[0] + $iOffset, $aiPos[1])
    Sleep(1)
    $aiPos = WinGetPos($hGUI)
EndFunc

Also worth noting is the fact that the problem isn't exclusively a problem with the left-hand side of the screen. It seems like it's the fact that the top-left corner of the icon control isn't actually visible while the control is moving (relatively) right-ward while getting "unhidden" that causes this to happen. Another way to demonstrate the problem would be to cover the control completely with another window, then move the covering window left-ward (so that the icon control is moving right-ward relative to the window). You'll see the issue occur here as well.

Basically, it looks like a repainting issue. If the tab control is removed, the problem no longer occurs. I've tried using WM_PAINT to manually redraw the icon control using RedrawWindow, but the background doesn't go away until the control is fully visible (which is slightly less than helpful -- I don't want to see the non-transparent background at all). What I'm wondering is... is there any way to prevent this from happening?

With 3.2.10.0 I don't see any difference between before the gui is moved off the screen and after.

With Beta 3.2.11.12 the background goes black only while it is being redrawn and the top left of the icon is hidden.

Looks like a bug to me.


Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.

Share this post


Link to post
Share on other sites

Nothing special here, using 3.2.12.0.


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

Share this post


Link to post
Share on other sites

Nothing special here, using 3.2.12.0.

Thanks monoceres, you're a step ahead with your version. Good to know the problem has been fixed.

Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.

Share this post


Link to post
Share on other sites

It's *not* fixed, else I would have posted otherwise -- I'm always using the latest version of AutoIt, stable or not.


[ WinINet.au3 | Array.au3 (Optimized) | _UnixTimeParse() ]

Share this post


Link to post
Share on other sites

It's *not* fixed, else I would have posted otherwise -- I'm always using the latest version of AutoIt, stable or not.

Are you using Vista or Xp? (I'm using Vista)

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

Share this post


Link to post
Share on other sites

It's *not* fixed, else I would have posted otherwise -- I'm always using the latest version of AutoIt, stable or not.

Calm down. You've said you're using 3.2.11.x. I'm using the latest Beta which is 3.2.11.12 and I get the same problem as you do. Monoceres is using the release candidate 3.2.12.0 which has not been released as the Beta yet, but he says there is no problem so I conclude the problem has been fixed. If you are also using 3.2.12.0 then I'm wrong.

Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.

Share this post


Link to post
Share on other sites

@martin: I am calm. Quite simply, text isn't exactly the best way to communicate voice inflection or word intonation. That said, yes, as I've implied, I'm currently running 3.2.12.0, and still see the problem.

@monoceres: XP indeed.


[ WinINet.au3 | Array.au3 (Optimized) | _UnixTimeParse() ]

Share this post


Link to post
Share on other sites

It's definitely a xp issue, was able to recreate the issue in my virtual machine with Win XP x64.


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

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