• 0

C++/Windows 7: Can't programmatically "hide" desktop icons


Question

I've been using C++ to send an LVM_DELETEITEM message to the desktop listview window, but it seems to be ignoring the index I give it.

It always seems to delete the same icon (last index), regardless of whichever index I send as the WPARAM.

I've tried using both Listview_DeleteItem() and SendMessage(LVM_DELETEITEM).

It seems Microsoft has subclassed the listview and are handling the LVM_DELETEITEM message differently to previous versions of Windows.

The code has been tested and working fine with WinXP x86, Vista (x86 and x64).

Both Win7 x86 and x64 are showing this strange behaviour.

Does anyone know of another way I can get this to work?

Any suggestions are welcome!

9 answers to this question

Recommended Posts

  • 0

This is a very flaky thing to be doing, and it shouldn't be surprising that it no longer works.

First, LVM_DELETEITEM was never designed to be sent directly by an external source (e.g., it's not like WM_KEYDOWN, which can be sent as the result of user input, and it's not designed to be sent by external apps). LVM_DELETEITEM is really more like an API, to allow the application that uses the list view control to communicate with the list view control, and since the list view control is implemented as a window, the API takes the form of window messages. Just because window messages can be sent by an external application doesn't mean that it should be sent, and this is one example of that. By injecting yourself into the private interactions of Explorer and its list view control, you may very well violate assumptions that Explorer may make about the state of the list view.

This is especially true for Explorer's main list view, since that list view is almost certainly a virtual list view, in which Explorer maintains much of the list view's state. Sending LVM_DELETEITEM from an external app in a situation like this is simply a bad idea, and it's surprising that this hack has even worked at all up to this point.

If you want to hide a file, why not just call SetFileAttributes and flip on the hidden bit?

(PS: Listview_DeleteItem is just a C macro that expands out to SendMessage LVM_DELETEITEM)

  • 0
  code.kliu.org said:
Sending LVM_DELETEITEM from an external app in a situation like this is simply a bad idea, and it's surprising that this hack has even worked at all up to this point.

If you want to hide a file, why not just call SetFileAttributes and flip on the hidden bit?

yes, i know its a bad idea and im not happy that i have to do this at all.

but ever since vista, the desktop has decided to simply ignore the hidden attribute on desktop.ini files

i'm just trying to make something that'll hide the icons without the need to delete the files.

  • 0
  twigboy said:
but ever since vista, the desktop has decided to simply ignore the hidden attribute on desktop.ini files

That's not Explorer's fault. Nor Vista's. It's simply doing what you are telling it to do. It still honors the hidden attribute. And the system attribute. desktop.ini has both +H and +S set. The desktop will only show desktop.ini if you enable "Show hidden files and folders" (which shows files with the +H bit) and uncheck "Hide protected operating system files" (which shows files with the +S bit). If you enable both of those options, then Explorer, by design, should show desktop.ini. If either one of those is not set, then desktop.ini will be hidden.

Incidentally, the reason why desktop.ini has the +S bit set is so that people can turn on "Show hidden files" and not have to see desktop.ini (aside from desktop.ini, very few files actually use the +S bit).

XP didn't have a desktop.ini for the Desktop folder, which is why you didn't see this in XP. But if you created a desktop.ini in XP, set the +H and +S attribs on it, but then enable the options to show +H and +S in Explorer, you'll see desktop.ini on your desktop, just like in Vista.

Now, if you insist on keeping both the "show +H" and "show +S" options enabled in Explorer, and you are bothered by the desktop.ini files, you can just delete them. It's only there so that it can show a special cute icon for the folder and use a localized display name, but if you care about neither of those things, you can just delete desktop.ini.

Edited by code.kliu.org
  • 0
  code.kliu.org said:
Now, if you insist on keeping both the "show +H" and "show +S" options enabled in Explorer, and you are bothered by the desktop.ini files, you can just delete them. It's only there so that it can show a special cute icon for the folder and use a localized display name, but if you care about neither of those things, you can just delete desktop.ini.

well yes, i do like having an icon for my desktop which is why i do not want to opt for the brute "delete the file" method.

  • 0
  code.kliu.org said:
This is especially true for Explorer's main list view, since that list view is almost certainly a virtual list view, in which Explorer maintains much of the list view's state. Sending LVM_DELETEITEM from an external app in a situation like this is simply a bad idea, and it's surprising that this hack has even worked at all up to this point.

If he insists on using the LVM_DELETEITEM method, wouldn't it be possible instead to inject a custom DLL into explorer, and send the LVM_DELETEITEM message through the injected process? If the reason being that explorer now ignores the LVM_DELETEITEM message from external apps it should work right? Not saying that this is a good idea either though. Just an interesting thought.

  • 0
  dlegend said:
... wouldn't it be possible instead to inject a custom DLL into explorer, and send the LVM_DELETEITEM message through the injected process?

yep, thats what i'm currently doing

i've subclassed it to make sure that the right message is being passed through and its correct up until the point where i have to process the LVM_DELETEITEM message

im wondering if theres a way to temporarily replace the custom LVM_DELETEITEM handler for the desktop with the default SysListview wndproc.

suggestions/advice still welcome!

  • 0
  dlegend said:
If he insists on using the LVM_DELETEITEM method, wouldn't it be possible instead to inject a custom DLL into explorer, and send the LVM_DELETEITEM message through the injected process?

That's not the problem. Whether the message comes from the Explorer process or not is irrelevant. The interaction between the list view and Explorer is just that: between the list view and Explorer, especially since the W7 list view is a virtual list view and Explorer is maintaining much of the list view state. It doesn't matter how you inject yourself into this.

If you are typing on your keyboard and your cat decides that it likes to walk on the keyboard, it's going to be disruptive regardless of whether your cat walks on the same keyboard that you are currently typing on or on a second keyboard connected to the same computer.

  twigboy said:
im wondering if theres a way to temporarily replace the custom LVM_DELETEITEM handler for the desktop with the default SysListview wndproc.

You can't--and most importantly, shouldn't--do this with LVM_DELETEITEM. Period. Nor would subclassing or "replacing" LVM_DELETEITEM work since this is a virtual list view where the list view itself does not maintain the state.

  twigboy said:
suggestions/advice still welcome!

If you really insist on showing +S files and having a cute icon for your desktop and hiding desktop.ini, then you have two options:

Option 1: Create a custom shell extension implementing the IExtractIcon interface that sets a cute, pretty icon for the desktop folder (thus bypassing the need for desktop.ini) and then delete desktop.ini.

Option 2: Get the IShellFolderView interface (hint) for the desktop shell view, find the desktop.ini object, and call IShellFolderView::RemoveObject on it.

Seems like a lot of effort to go through for a cute icon. :p

Disclaimer: I haven't actually tried either option. In theory, they should work, but as you can imagine, this isn't something that many people have tried doing before.

Edited by code.kliu.org
  • 0
  code.kliu.org said:
Option 2: Get the IShellFolderView interface (hint) for the desktop shell view, find the desktop.ini object, and call IShellFolderView::RemoveObject on it.

Seems like a lot of effort to go through for a cute icon. :p

thanks for that, i'll try it out and let you guys know how it goes.

i dont really mind the trouble. despite being much more difficult than deleting the files, its a good excuse to learn some new tricks :)

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • I'm sure Denmark would stand to lose a lot if US consumers stopped buying Danish products, whether that's Lurpak butter or hi-fi equipment.
    • JD Vance will be the next President. Who've the Democrats got? Harris again? lol....
    • Microsoft Edge gets new password feature and security fixes by Taras Buria Microsoft has released a new update for the Edge browser in the Stable Channel. Version 137.0.3296.83 introduces a new password feature and fixes security vulnerabilities to make your browsing experience safer. Starting with new features, Microsoft Edge 137 now supports Secure Password Deployment. Microsoft recently announced this for IT admins, allowing them to share encrypted passwords with user groups. This service lets users log into websites without seeing their passwords, thus enhancing the organization's security. You can read more about Microsoft Edge Secure Password Deployment in our recent article here. Security updates in Microsoft Edge 137.0.3296.83 include two fixes for Chromium vulnerabilities: CVE-2025-5958: Use after free in Media in Google Chrome prior to 137.0.7151.103 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) CVE-2025-5959: Type Confusion in V8 in Google Chrome prior to 137.0.7151.103 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) You can update Microsoft Edge to the latest version by heading to edge://settings/help. The browser can also update itself automatically in the background and apply updates between restarts. In case you missed it, Microsoft released Edge 137 by the end of May. The update deprecated quite a lot of existing features, including Wallet, Image Editor, Image Hover, Mini menu, and Video Super Resolution. It also introduced Web Content Filtering and enhancements for the picture-in-picture player and Find on Page in Microsoft Edge for Business. The next feature update for Microsoft Edge, version 138, is expected on the week of June 26, 2025, as part of the standard four-week release cadence.
    • Microsoft commits to upskill 1 million UK workers in AI this year by Paul Hill Microsoft has partnered with the UK government in the latter’s ambitious plan to train 7.5 million workers in AI skills over the next five years. Specifically, Microsoft has committed to upskilling 1 million of those workers by the end of this year. This represents a significant portion of the overall target and within a very short timeframe. The education drive by Microsoft builds on its previous “Get On” program, which has given 1.5 million people basic digital skills. The effort to train up 1 million British workers in AI is part of Microsoft’s broader £2.5 billion investment in UK AI infrastructure. Ensuring workers have the skills to leverage AI tools is important. Microsoft CEO UK Darren Hardman said recently that two-thirds of business people wouldn’t hire someone lacking AI skills, showing just how vital it is to get people’s skills up to date. Microsoft's approach to AI skills development Microsoft has several platforms to offer AI training, including Microsoft Learn, AI Skills Navigator, and through partnerships with non-profit organisations such as Catch22 in the UK. Its educational materials cover everything from the basics of generative AI to helping you prepare for advanced roles like being an AI engineer. With Catch22, Microsoft helps to train people who face various challenges to getting tech skills, including gender and ethnicity barriers, homelessness, mental health issues, school exclusion and disability. Microsoft is also trying to get more women into tech fields through programmes like TechHer, where it has trained thousands of women across UK government departments. Many of the courses that Microsoft offers come complete with certificates that you can show off on your CV when applying for a job to impress potential employers and land a job. Who else is partnering with the UK government? While Microsoft is playing a massive role in the government’s plans, it’s not the only big tech giant helping out. The firms that have partnered with the government are: Accenture, Amazon, Barclays, BT, Google, IBM, Intuit, Microsoft, Sage, SAS, and Salesforce. While all of these firms are helping to train workers, Microsoft’s planned efforts are the most notable. This initiative by the government will help the country brace for the changes AI is expected to bring to the economy. In April, the United Nations said that AI will affect 40% of all jobs, so being ready is a must.
    • Microsoft has an update on Exchange Online Basic Auth removal for Office 365 by Sayan Sen Back in 2022, Microsoft announced the retirement of Basic Authentication as it was moving to modern OAuth 2.0 token-based authentication. The reason was simple, to move away from such simple username-password authentication to more secure sign-ins. While Microsoft had previously planned to "permanently remove support for Basic authentication with Client Submission (SMTP AUTH) in September 2025", the company has now updated this timeline, adding a final delay. Perhaps this was on the cards given that Microsoft recently extended Basic Auth support for High Volume Email to 2028. On the Microsoft 365 Admin Center, a new message has been posted that details the changes regarding SMTP (Simple Mail Transfer Protocol) AUTH Client Submission. The message says: Thus, starting March 1, 2026, Exchange Online will begin phasing out Basic authentication for sending emails via SMTP AUTH. At first, fewer attempts will be blocked, but by April 30, 2026, this older method will be fully disabled. After that, any apps or devices that want to send email this way will need to use OAuth. The message further adds how admins can proceed with the changes in case OAuth is not supported: Users who have access to the M365 Admin Center can view the message under ID MC786329.
  • Recent Achievements

    • Week One Done
      LagFighterZ earned a badge
      Week One Done
    • First Post
      ThatGuyOnline earned a badge
      First Post
    • One Month Later
      5i3zi1 earned a badge
      One Month Later
    • Week One Done
      5i3zi1 earned a badge
      Week One Done
    • Week One Done
      julien02 earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      540
    2. 2
      ATLien_0
      224
    3. 3
      +FloatingFatMan
      160
    4. 4
      Michael Scrip
      115
    5. 5
      +Edouard
      91
  • Tell a friend

    Love Neowin? Tell a friend!