A reminder about the correct way of accessing and manipulating the position of icons on the desktop
A customer reported that their code to manipulate the position of icons on their desktop stopped working. It had worked “just fine” until the 19H1 update. The escalation engineer debugged the program and discovered that what it does is that it looks for its icons on the desktop and repositions them by hunting for the ListView control that holds the desktop icons, and then sending it a LVM_. They claim that this stopped working, and they want to know why.
It stopped working because it never was guaranteed to work in the first place.
Starting in Windows 10 version 1809, there were changes to the way that the positions of the desktop icons are managed, and one of the consequences is that if you try to manipulate the icon positions by talking directly to the ListView control, those changes aren’t taken into account by the icon management code, and your changes are lost.
The solution is to stop sending messages to an undocumented window to take advantage of internal implementation details, because the nature of implementation details is that they change when the implementation changes.
The supported API for manipulating desktop icons is IFolderView::, and that API still works. (As it should, because it’s the supported API.) You can look at some code I wrote many years ago for manipulating the position of desktop icons to see how it’s done.
Light
Dark
7 comments
Dear Mr Chen:
There is a question about set-parent function irrelevant to this subject.
My team want to use Set-Parent to create a parent/child relationship between windows which belong to different processes, we build a Demo Project, but the process included crash occasionally. Thus i look for the reason, i find your article named “Is it legal to have a cross-process parent/child or owner/owned window relationship?” In your opinion, it is technically legal, but is difficult to manage, not recommended for beginners.
The question is, your essay was written eight years ago, is this management problem still exist? There is not an expert like you in my team, do you still not recommended for beginners?
Looking forward to your reply. My email is leibinhua2008@163.com.
It’s hard for me to relate with people who obsess about the desktop because if you use your computer for serious work then you won’t see your desktop for years at a time and you may forget what the wallpaper even looks like.
I agree. I last set my desktop wallpaper on my old Win7 laptop some years ago. I’ve been on Win10 since that time and I haven’t changed the default wallpaper. I almost never see it, other than on the login screen. Fussing about the desktop icons (and going about it in an undocumented manner, no less) seems like a pointless waste of time.
I’m not narrow-minded to think that everyone uses their PCs the same way. I know of several people who use the desktop as their dumping ground for every file that they’ve ever downloaded or been sent, and refer to it regularly. And they insist that they “know where everything is” on the desktop.
I view this as a failing of the windows documentation more than anything. I correctly predicted that attempting to google this task would return 2 things, depending on the exactly search terms:
1. Your original blog post, which while very helpful, but doesn’t always show up first, and isn’t exactly official documentation. If I wasn’t familiar with your blog it wouldn’t stand out.
2. A StackOverflow post asking this exactly question, being answered with the exact unsupported answer described here. (I also found another StackOverflow post with an answer linking back to this one).
Regardless of what I searched, I was unable to find documentation for the above APIs without knowing the name of it beforehand, and even after finding it, it isn’t clear how that would apply to the desktop for somebody who doesn’t see “PCUITEMID_CHILD_ARRAY” and have some existing understanding of what that might mean. It’s not even a link to a page of relevant documentation about that item.
Try searching for “win32 shell namespace” and then take the link for “Introduction to the Shell Namespace”.
I’m not really looking for help, it’s not a task I’m currently needing to solve. I’m critiquing the documentation, which isn’t structured in a way that allows for useful problem solving or searching. (My major evidence is that the StackOverflow page is still the top result for many variations on this search).
Funnily enough, while I didn’t find that page, I found a word for word identical page (aside from the title) called “Common Explorer Concepts” which says it is out of date. Both of these pages include a screenshot of Windows 98.
I know windows APIs are complicated, and include a lot of Jargon that can be difficult to parse at first, and once you manage to stumble across the correct page of documentation, and google what exactly HWND is for the 20th time so it finally sticks, you can maybe solve your problem. But getting that entry point is tough.
A few ways to solve this would be to add common use cases to APIs, such as the “IFolderView::SelectAndPositionItems” you could say: “This can be used to rearrange the positions of files, folders, and other shell objects in Windows Explorer views.” It’s not a huge change, but now Google willing, it might show up in a search. Additionally, a code sample on the “IFolderView Overview” page would really help. Another approach would be to remove a decade old reference to TweakUI on this page and include a reference to a programmatic solution.
Obviously doing any this universally is a huge effort, but I think it would really help improve things.
I agree a lot of the documentation is just plain terrible. It use to be much better back before the “everything has to only be on the internet” craze took over.