Sign in to follow this  
Followers 0
ResNullius

GuiCtrlCreateIcon() BUG?

17 posts in this topic

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.

Share this post


Link to post
Share on other sites



@ResNullius,

Same result with 3.3.0.0 on Vista x32 Home Premium SP1.

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

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


I see fascists...

Share this post


Link to post
Share on other sites

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.


Giggity

Share this post


Link to post
Share on other sites

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".

Share this post


Link to post
Share on other sites

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


Giggity

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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(..............


George

Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.

Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.***

The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number.

Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else.

"Old age and treachery will always overcome youth and skill!"

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

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

Visit the SciTE4AutoIt3 Download page for the latest versions        Beta files                                                          Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

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

Giggity

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.


Giggity

Share this post


Link to post
Share on other sites

#13 ·  Posted (edited)

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

Visit the SciTE4AutoIt3 Download page for the latest versions        Beta files                                                          Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites

Ì 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?

Share this post


Link to post
Share on other sites

@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


Visit the SciTE4AutoIt3 Download page for the latest versions        Beta files                                                          Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

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