ICU - Icon Configuration Utility
Current Version: v6 (2018-Sep-16)
Restore your desktop when the icons get "rearranged".
Melba23 and I found we were working on very similar ideas to restore the Desktop icons to their normal place if they became "rearranged" (
). Vista seems to like this doing on occasion just for fun - but we all know some apps and games which change the display resolution or move icons around. This annoys "tidy" people who like their desktops arranged "just so" - I am particularly thinking of this desktop when I say that!
We combined efforts and here is the result of our labors.
Operation is easy - press "Save" to store a particular configuration and "Restore" to reset the icons to the saved positions in the selected configuration file. "Delete" allows you to remove unwanted configuration files from the list. There is a command line option so that the restoration can be run via HotKeys if required (that is why the script warns that it should be compiled for full functionality). You can decide what to do with any icons that have been added since you last saved the configuration file - the default is to put them in the top-left corner, but you can also banish them way off-screen or, more sensibly, specify a location for them.
A new feature as of ICU v3.4 is the optional Desktop Contextmenu Integration (DCI) for Win7 (Win7 only because Microsoft implemented an easy way to do this through the registry as of this release).
Version 3.3 should fix the empty save file bug
Version 3.4 Win7: Admin rights no longer needed for DCI
Version 5.0 Win8 compatibility for DCI
The source and executable can be downloaded from my site: http://www.funk.eu
Kudos to Ascend4nt, Melba23, Prog@ndy, & Valik for parts of the code.
Please let me know if you found some piece of code in the source for which I forgot to mention a credit.
Enjoy, let me know what you think of ICU and with Best Regards
I am trying to create a script to clean up users' desktops by moving all desktop folders and files (except the two hidden "desktop.ini" files and a MyDesktop.lnk shortcut) to a different folder. The script below will move files but not folders. The other issue with the script is that it doesn't seem to execute from a location other than the user's desktop. I would appreciate any suggestions.
#include <File.au3> MsgBox(64, "Desktop", "Cleaning up Desktop. This box will close in 4 seconds.", 4) $Files = _FileListToArray(@DesktopDir,"*",1) For $Index = 1 To $Files If StringRight($Files[$Index],4) <> ".ini, MyDesktop.lnk" Then FileMove($Files[$Index],'F:\HOME\Desktop') EndIf Next
I came here with maybe too specific questions about uncommon things, but as people says, I don't lose anything trying to asking here
There's long time that I have a little "experimental" idea: Use windows desktop and it icon system like old videogame consoles (where "sprites" are used to draw things on screen, can be manipulated/animated to make interesting things happen). Some of that inspiration came from another experiments from demoscene.
Researching the possibilities of doing something like that (maybe not so intense) I found that the Windows Desktop uses a GuiListView to show and arrange icons (and of course, AutoIt provides UDF's for that ). So, I'm used that UDF to create dummy icons (not putting files on Desktop, just modifiying the "GUI layer" of desktop for put non-working icons), setting custom values like coordinates, name and Icon (from a list of loaded icons in the GuiListView). As you can see in next image works well in Windows XP... even in Windows 95 (that's not the case from Windows Vista to 10, but I already posted another question here about that... anyways, for now I'm working that with a isolated XP machine... sigh).
Another video doing an animation with that:
How I make that custom icons? Here:
$hWnd = ControlGetHandle("Program Manager", "", "[CLASS:SysListView32; INSTANCE:1]") $newItem = _GUICtrlListView_AddItem ( $hWnd, "TEST", 32 ) ; with an icon of index 32 _GUICtrlListView_SetItemPosition ( $hWnd, $newItem, 300, 300 ) ; set some example property. Put in X=300 Y=300 Okay, so the next phase was changing the icons with custom ones. And here starts the issues. As AutoIT help says, icons from GuiListView came from a loaded GUIImageList, which, seeing past images I conclude that it's already preloaded with some sort of most used icons (something like an icon cache?). But If I modify it (or create another GUIImageList and then put into the GuiListView) the icons became corrupted and replaced with blank ones. (can be reverted deleting IconCache.db, just like when windows shows wrong icons in desktop).
How I change icons? Here
$hImage = _GUIImageList_Create(48, 48, 5) ; create an image list for 48x48 icons $newIcon = _GUIImageList_AddIcon($imageList, @SystemDir & "\shell32.dll", 110) ; just adding a new icon in the image list _GUICtrlListView_SetImageList($hWnd, $hImage, 0) ; $hwnd is the desktop hwnd Another option as workaround for setting icons was getting the desktop GUIImageList, and modifiyng it directly. I otbtain a GUIImageList handle, but ... without any images inside! (That's strange beacuse, when I set desktop item icons without altering the GUIImageList, it applies correctly). And finally if I try to add new ones, it returns -1 with @error setted.
How I'm trying to get desktop GUIImageList? Here.
$imageList = _GUICtrlListView_GetImageList ( $hWnd, 0 ) MsgBox(0,_GUIImageList_GetImageCount ( $imageList ), $imageList) ; getting image count and GUIImageList handle $newIcon = _GUIImageList_AddIcon($imageList, @SystemDir & "\shell32.dll", 110) ; adding icons without success So, what is the question? There's something wrong I'm doing while trying to set the new icon set on desktop? Or desktop icons work in different way than the rest of the GuiListView's? Or there's something really stupid that I can't saw before that corrupts the icons?
Also... if there's not known solution for that, do you have some idea for doing a workaround for that? Or another crazy idea? (Maybe putting real files instead dummy icons could be a solution ... a very slow one). Or even maybe (maybe not, I sure about that xD) do you want to help with this "experiment".
Thanks in advance, have a good day
How can i make function _ExplorerGetSelectedItems get selecteds items on the Desktop?
Func _ExplorerGetSelectedItems($sCabinetWClass="[CLASS:CabinetWClass]") Local $Ret = "" Local $aIndexes, $sSelected, $sSelected_Path Local $hSearch, $sCurrentFile $sSelected_Path = ControlGetText($sCabinetWClass, "", "Edit1") ConsoleWrite($sSelected_Path&@CRLF) $aIndexes = StringSplit(ControlListView($sCabinetWClass, "", "SysListView321", "GetSelected", 1), "|") If $aIndexes = 1 And ($aIndexes == "" Or $aIndexes = 0) Then Return SetError(1, 0, 0) For $i = 1 To $aIndexes $sSelected = ControlListView($sCabinetWClass, "", "SysListView321", "GetText", $aIndexes[$i]) $sCurrentFile = StringRegExpReplace($sSelected_Path, "\\+$", "") & "\" & $sSelected If Not FileExists($sCurrentFile) Then ;Search the extension for file... $hSearch = FileFindFirstFile($sCurrentFile & ".*") If $hSearch <> -1 Then $sSelected = FileFindNextFile($hSearch) FileClose($hSearch) EndIf EndIf ;Check if item is a directory If StringInStr(FileGetAttrib($sCurrentFile), "D") > 0 Then $sSelected = "*"&$sSelected $Ret = $Ret&$sSelected&Chr(10) Sleep(1) Next Return $Ret EndFunc
Hey could be interesting to the AutoIt devs out there
Will win32 apps (autoit apps) work in the new windows 10 store?
Early days yet won't be in the initial win 10 release...
Note win32 apps are now called many things
- desktop apps
- CWA ( Classic Windows Apps - not country womens ..assoc. )
- Project C(entenial) apps
These apps will not be sandboxed but NOT be allowed to run as admin , all files will be sandboxed installation handled through the store..
How does this affect autoit - ?
following as not supported in Project C apps:
“Windows NT Services”, “Things running in the kernel” (device drivers) “System Level Software” (anything not running in the user context) “Elevation”, meaning anything that causes a standard user to get a UAC prompt “will be blocked”. Using parts of other apps in your app, at least in version 1. John indicated that they would like to support extensibility and plug-ins, just probably not initially. The implication was that this might be a direct UWA thing and not specific to Project C, but we can’t be sure.
following as supported in Project C apps:
“COM” “WMI” “Networking” “Anything else a standard app does that isn’t in the system space”. I am guessing that there are a lot of other things that might end up in the ‘not supported’ list that you might have thought falls under the last item in the supported list but turns out is not supported, but we just don’t know yet:
WMI Providers Windows Timed and Triggered Events (but they can write new UWA background triggers) Custom ETW Providers COM localsystem (out of process) running as the system to avoid UAC prompts Maybe DCOM Software Clients, Application Capabilities Shell Extensions, Browser Helper Objects, and the like