ResNullius Posted January 5, 2009 Share Posted January 5, 2009 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() = -3Regression 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. Link to comment Share on other sites More sharing options...
Moderators Melba23 Posted January 5, 2009 Moderators Share Posted January 5, 2009 @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 Open spoiler to see my UDFs: Spoiler ArrayMultiColSort ---- Sort arrays on multiple columnsChooseFileFolder ---- Single and multiple selections from specified path treeview listingDate_Time_Convert -- Easily convert date/time formats, including the language usedExtMsgBox --------- A highly customisable replacement for MsgBoxGUIExtender -------- Extend and retract multiple sections within a GUIGUIFrame ---------- Subdivide GUIs into many adjustable framesGUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView itemsGUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeViewMarquee ----------- Scrolling tickertape GUIsNoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxesNotify ------------- Small notifications on the edge of the displayScrollbars ----------Automatically sized scrollbars with a single commandStringSize ---------- Automatically size controls to fit textToast -------------- Small GUIs which pop out of the notification area Link to comment Share on other sites More sharing options...
rover Posted January 5, 2009 Share Posted January 5, 2009 @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... Link to comment Share on other sites More sharing options...
youknowwho4eva Posted January 5, 2009 Share Posted January 5, 2009 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 Link to comment Share on other sites More sharing options...
ResNullius Posted January 5, 2009 Author Share Posted January 5, 2009 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() = -3I 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". Link to comment Share on other sites More sharing options...
youknowwho4eva Posted January 5, 2009 Share Posted January 5, 2009 What about deleting the control before creating the default icon? Or making it hidden unless the value <>0? Giggity Link to comment Share on other sites More sharing options...
ResNullius Posted January 5, 2009 Author Share Posted January 5, 2009 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... Link to comment Share on other sites More sharing options...
GEOSoft Posted January 5, 2009 Share Posted January 5, 2009 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!" Link to comment Share on other sites More sharing options...
Developers Jos Posted January 5, 2009 Developers Share Posted January 5, 2009 (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 January 5, 2009 by Jos SciTE4AutoIt3 Full installer Download page - Beta files Read before posting How to post scriptsource Forum etiquette Forum Rules Live for the present, Dream of the future, Learn from the past. Link to comment Share on other sites More sharing options...
youknowwho4eva Posted January 5, 2009 Share Posted January 5, 2009 (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 January 5, 2009 by youknowwho4eva Giggity Link to comment Share on other sites More sharing options...
ResNullius Posted January 5, 2009 Author Share Posted January 5, 2009 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? Link to comment Share on other sites More sharing options...
youknowwho4eva Posted January 5, 2009 Share Posted January 5, 2009 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 Link to comment Share on other sites More sharing options...
Developers Jos Posted January 5, 2009 Developers Share Posted January 5, 2009 (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 January 5, 2009 by Jos SciTE4AutoIt3 Full installer Download page - Beta files Read before posting How to post scriptsource Forum etiquette Forum Rules Live for the present, Dream of the future, Learn from the past. Link to comment Share on other sites More sharing options...
ResNullius Posted January 5, 2009 Author Share Posted January 5, 2009 Ì 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? Link to comment Share on other sites More sharing options...
Developers Jos Posted January 5, 2009 Developers Share Posted January 5, 2009 @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 SciTE4AutoIt3 Full installer Download page - Beta files Read before posting How to post scriptsource Forum etiquette Forum Rules Live for the present, Dream of the future, Learn from the past. Link to comment Share on other sites More sharing options...
Developers Jos Posted January 5, 2009 Developers Share Posted January 5, 2009 BugReport: http://www.autoitscript.com/trac/autoit/ticket/763 SciTE4AutoIt3 Full installer Download page - Beta files Read before posting How to post scriptsource Forum etiquette Forum Rules Live for the present, Dream of the future, Learn from the past. Link to comment Share on other sites More sharing options...
ResNullius Posted January 5, 2009 Author Share Posted January 5, 2009 BugReport: http://www.autoitscript.com/trac/autoit/ticket/763Thanks Jos! Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now