GuiCtrlCreateIcon() BUG?

[ResNullius]

AutoIt v3.3.00, Win XP Pro w/ SP3.

Create an icon control with a non-existent file name for the icon and AutoIt returns "0" indicating failure, as it should.

However, the icon control is still created as indicated by the grey box, and the output of WinGetClassList() in the following example:

$gui = GuiCreate("TEST")
GUISetBkColor(0x0A659C)

$a = GUICtrlCreateIcon(@SystemDir & "\shell32.dll", -22, 10, 10, 32, 32)
ConsoleWrite("$a = " & $a & @CRLF)

;$b = GUICtrlCreateIcon(@SystemDir & "\shell32.dll", -22, 10, 54, 32, 32)
$b = GUICtrlCreateIcon("aNonExistantFileName.dll", -22, 10, 52, 32, 32)
ConsoleWrite("$b = " & $b & @CRLF)

$c = GUICtrlCreateIcon(@SystemDir & "\shell32.dll", -22, 10, 94, 32, 32)
ConsoleWrite("$c = " & $c & @CRLF)

$ClassList = WinGetClassList($gui)
ConsoleWrite(@CRLF & "CLASS LIST" & @CRLF & "==========" & @CRLF & $ClassList & @CRLF)

ConsoleWrite(@CRLF)
    
GUISetState()

Do
    Sleep(10)
Until GUIGetMsg() = -3

Regression testing indicates the behaviour changed somewhat after v3.2.2.0.

In 3.2.2.0 the behaviour is similar, except that you don't get the grey box showing up. But if you use Au3Info with "higlight controls" turned on, you can still see the spot where the control exists.

Questions:

1) can others please verify this before I trundle off to the Bug Trac?

2) should not the control be deleted on failure to create it properly? The same thing works as expected with a GuiCtrlCreatePic(), that is: if you specify an invalid path for the source pic, no "phantom" picture control is created.

[Melba23]

@ResNullius,

Same result with 3.3.0.0 on Vista x32 Home Premium SP1.

M23

[rover]

@ResNullius

same here

v3.3.0.0 and v3.2.12.0

XP Pro SP2

an undeletable static control with a control ID of 0

trac away

[youknowwho4eva]

I would think that a blank icon would be ideal over the icon being skipped. If you have an automated creation of icons and an icon file doesn't exist, you still want to be able to access that item. I can't think of a good example... Maybe something like an unknown file type. instead of MS not having the icon at all it supplies the default icon for unknown file type. It would be up to the scriptwriter to have a fail safe that if icon doesn't exist (=0) then to use a default icon. I personally would prefer a grey box over nothing being shown at all as well.

[ResNullius]

It would be up to the scriptwriter to have a fail safe that if icon doesn't exist (=0) then to use a default icon.

I am trying to do just that.

You can do a FileExists() check beforehand for the icon file itself, but how do you check for the existence of the icon within say a dll? i.e: system32.dll, -500

So I thought, OK, I'll check the return code of the control creation, and if that's 0, then I'll rerun the creation using a icon that is known to exist (in this case from a FileInstall).

Problem is that in using a replacement icon the part of the grey box is still visible behind the new icon set to the same pos & size.

See this modified example:

$gui = GuiCreate("TEST")
GUISetBkColor(0x0A659C)

$a = GUICtrlCreateIcon(@SystemDir & "\shell32.dll", -22, 10, 10, 32, 32)
ConsoleWrite("$a = " & $a & @CRLF)

;$b = GUICtrlCreateIcon(@SystemDir & "\shell32.dll", -22, 10, 54, 32, 32)
$b = GUICtrlCreateIcon("aNonExistantFileName.dll", -22, 10, 52, 32, 32)
ConsoleWrite("$b = " & $b & @CRLF)
If $b = 0 then 
    $b = GUICtrlCreateIcon(@SystemDir & "\shell32.dll", -22, 10, 54, 32, 32)
    ConsoleWrite("New $b = " & $b & @CRLF)
EndIf


$c = GUICtrlCreateIcon(@SystemDir & "\shell32.dll", -22, 10, 94, 32, 32)
ConsoleWrite("$c = " & $c & @CRLF)

$ClassList = WinGetClassList($gui)
ConsoleWrite(@CRLF & "CLASS LIST" & @CRLF & "==========" & @CRLF & $ClassList & @CRLF)

ConsoleWrite(@CRLF)
    
GUISetState()

Do
    Sleep(10)
Until GUIGetMsg() = -3

I personally would prefer a grey box over nothing being shown at all as well.

Also, since the "failed" icon control has no GuiCtrl number, you can't do anything with it anyway, so the grey box being shown isn't very helpful. Either way it's buggy.

I'd at least prefer the behaviour under 3.2.2.0 where the failed icon placeholder is the same colour as the gui background, and a new icon can be laid overtop without any visual "uckiness".

[youknowwho4eva]

What about deleting the control before creating the default icon? Or making it hidden unless the value <>0?

[ResNullius]

What about deleting the control before creating the default icon? Or making it hidden unless the value <>0?

The failed control doesn't have a valid handle, so you can't delete it.

And GuiCtrlDelete(-1) just ends up deleteing the last succesfully created control, not the failed one.

You would have to resort to regular Window Control Functions, enumerate the controls in the window and try to find the right one (since GuiCtrlGetHandle() also won't work).

I would think we should be able to deal with this using the GuiCtrl functions...

[GEOSoft]

One could safely assume that this is normal behavior. It failed because the file did not exist not because it was unable to create the control.

You could solve it simply by using If FileExists($icon) Then GUICtrlCreateIcon(..............

[Jos]

One could safely assume that this is normal behavior. It failed because the file did not exist not because it was unable to create the control.

You could solve it simply by using If FileExists($icon) Then GUICtrlCreateIcon(..............

The Control gets created successfully but only setting it to the ICON fails, so I would expect either the Ctrl to be Deleted or the hWnd to be returned. Edited January 5, 2009 by Jos

[youknowwho4eva]

I just played with it some, and it does act very odd. It creates an uncontrollable control. So if you had a transparent Icon you would see the gray there instead of the background color. I must agree that the control should not be created if the icon doesn't exist in the capabilities of the guictrlcreateicon function now. I would personally rather it create the gray box, but be able to delete it if that's not what you want.

Edit: Yea what Jos said

Edited January 5, 2009 by youknowwho4eva

[ResNullius]

The Control gets created successfully but only the setting it to the ICON fails so I would expect either the Ctrl to be Deleted or the hWnd to be returned.

So one way or another the current behaviour is buggy?

[youknowwho4eva]

Hmmm buggy or set up in a way that has a slight hole in the design. I guess buggy seeing the return of 0 helps nothing other then if you are troubleshooting your program. In this cause it actually hinders because you create a control with no controlid.

[Jos]

So one way or another the current behaviour is buggy?

Ì would say yes.

I won't touch the GUI code but had a quick look and see that the Handle gets deleted because the UpdateICON() routine fails, but the created control doesn't get deleted. So in my oppinion we either have to return the handle for the created Control or Delete the control when the UpdateICON() fails.

Jos

Edited January 5, 2009 by Jos

[ResNullius]

Ì would say yes.

I won't touch the GUI code but had a quick look and see that the Handle gets deleted because the UpdateICON() routine fails, but the created control doesn't get deleted. So in my oppinion we either have to return the handle for the created Control or Delete the control when the UpdateICON() fails.

Jos

@Jos,

Shall I open a ticket on Bug Trac then? Or will you do that now you know what's up?

[Jos]

@Jos,

Shall I open a ticket on Bug Trac then? Or will you do that now you know what's up?

Let me open it for you because I am able to do that without tweaking Trac.

Jos

[Jos]

BugReport: http://www.autoitscript.com/trac/autoit/ticket/763

[ResNullius]

BugReport: http://www.autoitscript.com/trac/autoit/ticket/763

Thanks Jos!