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
Two tiny, simple scripts (secondDesktop & desktopSwitch) that elaborate (slightly) on _WinAPI_CreateDesktop() to create a second workspace with some interesting features:
Startup: define any number of programmes to be auto-started on the second desktop, hard-coded (by you, in desktopSwitch.au3) or parsed as parameters (from secondDesktop.au3); Full desktop mode: provides acccess to all your desktop shortcuts, start menu (Win7), taskbar, plus a one-button switch in both desktops; Kiosk mode: provides an empty workspace where only your designated startup entries will run; Switch button/GUI is absent; an unadvertised hotkey provides switching to the original desktop (Ctrl-Alt-Del still works, but a task manager started on the second desktop will appear on the original desktop). To enable kiosk mode, set flag $kioskmode=True in secondDesktop.au3; Security: software keyloggers running in your regular environment cannot capture keystrokes on the second desktop, and windows messages cannot be sent between desktops, so your apps won't be hijacked easily through remote control. (NB not extensively tested; use at your own risk!) In full desktop mode, the (red or green) background colour of the Switch GUI shows you whether you are on the exposed or secure desktop. I SecondDesktop.v0.8.7z (first beta release)
Important: you'll need to compile desktopSwitch before running secondDesktop. You can test your edited version of desktopSwitch.au3 "dry," as a script on your regular desktop first, by setting its internal flag $testing=True; but don't forget to reset that flag again before compiling.