[x64 & x32 fix] DeskIcons - Get/Set Desktop Icon Positions

[Drugwash]

@ iPhilip & joedf: Maybe some code and tips from Desktop Restore by Jamie O'Connell could be of help in some way.

[joedf]

Nice find!

[Drugwash]

Thanks. I've been using that tool for about two years, some 1.6.3 version. It even worked on the 98SE machine, with the help of KernelEx and some fiddling around. Unfortunately it can't save/restore those darn toolbars and the Quick Launch.

[fiffunD]

I created the script, however I dont see how to use it. Is a button or addition to a drop-down menu hiding from me somewhere? Thank you

[joedf]

Thanks. I've been using that tool for about two years, some 1.6.3 version. It even worked on the 98SE machine, with the help of KernelEx and some fiddling around. Unfortunately it can't save/restore those darn toolbars and the Quick Launch.

Have you tried my suggestion with naming them 1.lnk, 2.lnk, etc then manually change the shortcut descriptions?

I created the script, however I don't see how to use it. Is a button or addition to a drop-down menu hiding from me somewhere? Thank you

It's a function, you have to use it accordingly. Have you tried the example?

Code: Select all

; save positions
coords := DeskIcons()
MsgBox now move the icons around yourself
; load positions
DeskIcons(coords)

[Drugwash]

Thanks. I've been using that tool for about two years, some 1.6.3 version. It even worked on the 98SE machine, with the help of KernelEx and some fiddling around. Unfortunately it can't save/restore those darn toolbars and the Quick Launch.

Have you tried my suggestion with naming them 1.lnk, 2.lnk, etc then manually change the shortcut descriptions?

No. Have you? Because it doesn't work that way. A BaseBar control actually contains a Rebar control that hosts a Toolbar control, much like the Taskbar's Quick Launch (at least in 9x and XP). All those icons appearing in the bar are actually toolbar buttons, and their order is saved somewhere regardless of the link name.
Then, when sorting gets shuffled for whatever reason, the bar will automatically sort those icons by their given name, not by the link name. Therefore such effort would be pointless.
The key is to find out how/where the button order is being kept in memory during a session in a ToolbarWindow32 control, then retrieve that data, find out where it should be saved (the system does that only upon shutdown/reboot) and then just forcibly save it or keep it handy for recovery.

[joedf]

Can't test it unless I setup a virtual machine... :/

[rhinox202]

I am having the same issue. Windows 10 x64 FCU. Currently I have this script in a larger script which has #Warn enabled. As a result, when it's not working, I receive a couple errors. Both are variables without assigned values. The latter is probably caused by the former but that would be more your department Hopefully this is helpful. If you need any other info, just ask.

iProcessID in hProcess := DllCall("OpenProcess" , "UInt", 0x438, "Int", FALSE, "ptr", iProcessID)
ret in Return, ret after DllCall("CloseHandle", "ptr", hProcess)

A little over a year ago I posted the above question. I was having an issue with hProcess not having a value because hwWindow and iProcessID didn't have a value. Long story short, I got around to looking at this and determined that the issue was twofold. First, neither ControlGet was getting a value. Changing A (active window) to ahk_class WorkerW partially fixed that (thanks r0IZ). Second, DetectHiddenWindows was preventing a value from being read. I have a large script and this was turned on at the top. This function not working in my script always baffled me because it worked fine in a script by itself. Very strange!

So, in case anyone else stumbles across this issue, below is the code I'm using. I started with a base of r0IZ's code. Merged his detection of x64 (A_PtrSize == 8) to remove duplicate code. Added disabling of DetectHiddenWindows and later restore. Removed the extra date code (ControlGet, list5, list, Col5) for targeting files that have the same name (file size is already used, figured it was enough). Col5 didn't work anyway, I believe the value should be Col4. That is, if someone wants to add it back. Hopefully someone finds this helpful.

Code: Select all

DeskIcons(coords := "")
{
	Critical
	static MEM_COMMIT := 0x1000, PAGE_READWRITE := 0x04, MEM_RELEASE := 0x8000
	static LVM_GETITEMPOSITION := 0x00001010, LVM_SETITEMPOSITION := 0x0000100F, WM_SETREDRAW := 0x000B

	tempDetect := A_DetectHiddenWindows
	DetectHiddenWindows, Off
	ControlGet, hwWindow, HWND,, SysListView321, ahk_class Progman
	if !hwWindow ; #D mode
		ControlGet, hwWindow, HWND,, SysListView321, ahk_class WorkerW
	IfWinExist ahk_id %hwWindow% ; last-found window set
		WinGet, iProcessID, PID
	hProcess := DllCall("OpenProcess"   , "UInt",   0x438 ; PROCESS-OPERATION|READ|WRITE|QUERY_INFORMATION
				, "Int",   FALSE ; inherit = false
				, "UInt",   iProcessID)
	if hwWindow and hProcess
	{   
		ControlGet, list, list, Col1         
		ControlGet, list2, list, Col2
		Loop, Parse, list2, `n
			filetype_%A_Index% := SubStr(A_LoopField, 1, InStr(A_LoopField, " ") - 1)
		
		if !coords
		{
			VarSetCapacity(iCoord, A_PtrSize * 2)
			pItemCoord := DllCall("VirtualAllocEx", "UInt", hProcess, "UInt", 0, "UInt", 8, "UInt", MEM_COMMIT, "UInt", PAGE_READWRITE)
			Loop, Parse, list, `n
			{
				SendMessage, %LVM_GETITEMPOSITION%, % A_Index-1, %pItemCoord%
				DllCall("ReadProcessMemory", "UInt", hProcess, "UInt", pItemCoord, "UInt" . (A_PtrSize == 8 ? "64" : ""), &iCoord, "UInt", A_PtrSize * 2, "UIntP", cbReadWritten)
				iconid := A_LoopField . "(" . filetype_%A_Index% . ")"
				ret .= iconid ":" (NumGet(iCoord) & 0xFFFF) | ((Numget(iCoord, 4) & 0xFFFF) << 16) "`n"
			}
			DllCall("VirtualFreeEx", "UInt", hProcess, "UInt", pItemCoord, "UInt", 0, "UInt", MEM_RELEASE)
		}
		else
		{
			SendMessage, %WM_SETREDRAW%, 0, 0
			Loop, Parse, list, `n
			{
				iconid := A_LoopField . "(" . filetype_%A_Index% . ")"
				If RegExMatch(coords, "\Q" . iconid . "\E:\K.*", iCoord_new)
					SendMessage, %LVM_SETITEMPOSITION%, % A_Index - 1, %iCoord_new%
			}
			SendMessage, %WM_SETREDRAW%, 1, 0
			ret := true
		}
	}
	DllCall("CloseHandle", "UInt", hProcess)
	DetectHiddenWindows, % tempDetect
	return ret
}

[joedf]

Thanks for sharing this

[jeeswg]

I've added a section to my Explorer tutorial called 'MOVE OFF-SCREEN DESKTOP ICONS BACK TO VISIBLE AREA'. This trick is really handy:
[set icon size from medium to small to medium]
right-click, View, small icons
right-click, View, medium icons
[note: you may want to take a printscreen, to backup the icon order, before moving icons]

@rhinox202: This can be useful to get info for desktop files, although I haven't found any code for getting/setting icon positions:
[get access to the desktop shell object]
Create new file in current explorer window? - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=9618&p=53361#p53361

[JoeWinograd]

Hi joedf (or anyone else who wants to jump in),
I just discovered this script...first, let me say, very nice!

I tested it on W7/64-bit with a 3-monitor config; W10/64-bit, 1-monitor; W10/32-bit, 1-monitor. All worked perfectly!

I'm trying to understand how the script works...specifically, how the coords value maps to a location on the screen. I'm thinking that it's probably X/Y-coordinate related, but I can't figure it out. The coords values seem to be be 6-, 7-, and 8-digit numbers. Examples:

133735
6816732
20187976

In reviewing the results from all three systems, there are no values that are fewer than six digits or more than eight digits. But I can't discern a pattern that explains how a coords value maps to a screen location. Do you know? Thanks much, Joe

[joedf]

I haven't touched this for quite some time, but if I remember correctly... They are flag-based ish Hexadecimal numbers,... I don't have much time right now at the time of this post, but you check and see if there's a pattern when changing to hexadecimal numbers.
Let me know

[JoeWinograd]

Ah, brilliant...hex is the ticket! After converting to hex, the first four hex digits are the Y/vertical coordinate and the second four hex digits are the X/horizontal coordinate. Thanks very much!

[JoeWinograd]

Update on my last post. That analysis was from the results of a 1-monitor system. The results from a 3-monitor system show that the second four hex digits are probably composed of two 2-digit values, with the second 2-digit value being the X/horizontal coordinate, while the first 2-digit value seems to indicate the monitor (no doubt what you meant earlier by "flag-based"). Here are the hex values:

00 - left monitor (extended)
0A - middle monitor (main)
14 - right monitor (extended)

It's actually a 4-monitor system with one of the monitors disconnected. Windows "Identify" shows the left monitor as 3, the middle as 2, the right as 4, and the disconnected one as 1. I don't know how (or even if) the 2-digit hex value relates to the Windows "Identify" number. Regards, Joe

[Drugwash]

Coordinates can be negative, depending on which monitor is set as primary and how they are arranged (horizontally and/or vertically).
So you have to take into consideration signed integers.

[JoeWinograd]

Yes, X coordinates can be negative, and that's the case with my left monitor as reported by WinSpy (since my middle one is Main), but that's not the case with the coords values. For example, here are the values for the top row, first two icons:

left monitor
131085 0x0002000D
131160 0x00020058

middle monitor (main)
133645 0x00020A0D
133720 0x00020A58

right monitor
136205 0x0002140D
136280 0x00021458

The monitors are arranged horizontally. Regards, Joe

[Drugwash]

Based on the values it could mean all your monitors have a horizontal resolution of 2560px. That would explain the 00/0A/14*0x100.
BTW, the vertical coordinates can also be negative if monitors are stacked vertically. But negative values seem to not be used here.

[JoeWinograd]

all your monitors have a horizontal resolution of 2560px

Ah, great observation! The left and middle monitor are 2560 wide (right one isn't, but that's irrelevant). So, the X value is obviously zero-based, meaning the middle monitor starts at 2560=0x0A00 and the right starts at 5120=0x1400.

the vertical coordinates can also be negative if monitors are stacked vertically

Makes sense, but I've never stacked 'em vertically.

But negative values seem to not be used here.

Yep!

[joedf]

Interesting, great work guys! That's what I had in mind about the number structure, but I didn't know about all this other stuff! Cool!

[Xtra]

Works great!