I have a Windows shell extension that uses IShellIconOverlayIdentifier interface to display overlay icons on files and folders. My extension is a little like TortoiseCVS or TortoiseSVN.
Sometimes I need to make Windows Explorer redraw all it's icons. To do this, I call SHChangeNotify like this:
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, NULL, NULL)
This refreshes the desktop and right hand pane of any open explorer windows. It doesn't refresh the folder tree on the left hand side of any Explorer windows.
So I tried sending WM_SETTINGCHANGE like this:
SendMessage(HWND_BROADCAST, WM_SETTINGCHANGE, 0, 0)
on Vista this refreshes the folder tree, but not the right hand pane.
The combination of SHChangeNotify() followed by WM_SETTINGCHANGE seems to work quite well on Vista. But I still can't refresh the folder tree on XP if it is displayed.
Does anyone have any ideas how to do this better?
Is there a better solution for XP?
Sending SHCNE_ASSOCCHANGED is a bit like clubbing Explorer over the head. It causes the whole desktop to refresh quite violently and casues any open Explorer windows to loose there scroll position. Is there anything that's a bit less violent?
Does anyone have any ideas how to do
this better?
Personally I don't know. You mention the Tortoise programs which do a similar thing, so an excellent starting point would be to have a look at what they do in their source :)
These look to be the relevant source files that handle this problem:
TortoiseCVS - ShellUtils.cpp
TortoiseSVN - ShellUpdater.cpp (username: "guest", password: "")
I note in the RebuildIcons method in each of those will:
set the shell icon size or colour depth to a temporary value
updates all the windows by broadcasting the setting change
resets the shell icon size or colour depth to the original value
updates all the windows a second time with a broadcast of the setting change
Perhaps this is part of the trick to get things working in XP.
Use spy++ to see what WM_COMMMAND message gets sent when you press F5 in windows explorer or find what menu message is used for view/refresh
Then use FindWindow to get the explorer window you want and send the WM_COMMAND recorded earlier etc message to it.
This is a fun way to control all sorts of Windows programs.
You can also send a WM_KEYDOWN message with the F5 keycode to all open explorer windows. This is a bit of a hack though.
Related
i have been trying to get a windows startup/shutdown sound to play, i couldn't get the sounds to play so i asked on Microsoft, here is the link https://answers.microsoft.com/en-us/windows/forum/all/cannot-change-windows-start-up-sound/8bbcb0a0-1402-4f1e-b080-9c8d526bc205
and i was told that its not possible. well too bad because i am not going to stop there, so i went to local group policy editor on windows 10 where you can choose scripts to run during shutdown and start up. i then wrote a very small PowerShell command with the file name of "shutdown.ps1" the code inside of shutdown.ps1 is
start "C:\Windows\System32\GroupPolicy\Machine\Scripts\Shutdown\TADA.wav"
this file is located in the C:\Windows\System32\GroupPolicy\Machine\Scripts\Shutdown directory along with the TADA.wav file that it plays when it shuts down.
now the issue i am having is that when windows is shutting down, its ending all processes so it does not play the sound. what can i do to change that?
I'm pretty new to all of this and am very grateful for any input you can give.
thanks in advance,
Devin
From How to Change the Windows 10 Logoff, Logon, and Shutdown Sounds in Windows 10:
...
While you can still customize what sounds sounds play for most OS events, Windows 10 hid shut down, logoff, and logon from view. They’re still around, though. You just need to make a few mild changes in the Windows Registry to get them back.
Add the Actions Back to the Sound Control Panel by Editing the Registry
To add the shutdown, logoff, and logon actions back to the menu in the Sound Control Panel app, you just need to make a few little tweaks in the Windows Registry.
...
Open the Registry Editor by hitting Start and typing “regedit.” Press Enter to open Registry Editor and then give it permission to make changes to your PC.
In the Registry Editor, use the left sidebar to navigate to the following key:
HKEY_CURRENT_USER\AppEvents\EventLabels
You’re going to be making one small change in each of three different subkeys inside that EventLabels key. First, we’ll tackle the shutdown sound or, as Windows likes to call it, System Exit. Under the EventLabels key on the left side of Registry Editor, select the SystemExit subkey. On the right side, double-click the ExcludeFromCPL value.
Note that by default, the value is 1, meaning that the action is excluded from the Control Panel. Change the value to 0 and then click “OK.”
Next, you’re going to make exactly the same change in two other subkeys inside the EventLabels key: WindowsLogoff and WindowsLogon. Head into each of those folders, open the ExcludeFromCPL value inside, and change the value from 1 to 0.
No need to restart Windows. You can go ahead and test your changes right away. Open up the Sound Control Panel app by right-clicking the speaker icon in your Notification Area and selecting “Sounds.” 1
You should now see the new actions (Exit Windows, Windows Logoff, and Windows Logon) available in the selection window and you can assign whatever sounds you like to those actions.
If, for whatever reason, you want to hide those actions from the Control Panel again, just head back into Registry Editor and change each of those ExcludeFromCPL values back to 1.
1: On my machine, to get to the Sounds control panel, I had to go into the Settings, choose "Personalization", then "Themes", then `Sounds".
UPDATE:
And indeed, all three sound events show up in my Sounds control panel once I re-enable them in the Registry. However, I tried assigning audio files to them, and although Windows remembered the assignments, nothing played when invoking those actions.
So, I guess the playback functionality is simply not implemented for those events anymore. This seems to be confirmed in your discussion with a Microsoft Insider on answers.microsoft.com (with an 89% upvote rate of 143K replies, I would think he knows what he's talking about):
In Windows 10 there is no way to change the Windows Startup Sound, that sound is set permanently in a DLL in Windows, it is not an audio file like the other system sounds, and even when you turn on the Startup sound on that dialog, sometimes the startup sound will play and other times it will not, this is a known bug in Windows 10, which seems to have been fixed in Windows 11
Windows10 does not support a shutdown sound like previous versions of Windows, you wil find many methods posted online, sadly, none of them work.
this has been bugging me for quite a while now.
I'm using two monitors and usually have the main window of Visual Studio open on the primary monitor and things like the solution explorer, call stack, error list, output etc. on the second monitor in two separate windows which I split vertically by using the [Win] + [Left | Right] shortcut.
In another environment, this works fine (VS 2013, different machine). Of course, the window positions etc. are different between debug and regular view, but that's not really an issue.
Whenever I start debugging, the solution explorer window moves towards the right on the second monitor. This might even affect the other window (which contains the Call Stack, Output etc.).
After a few debug sessions, the window will be barely visible any more because it has moved so far towards the right...
This is even worse when I have multiple solutions open because then the solution explorer window that I see is actually the one from the instance in the background...
Has anyone else experienced this? Any ideas how to fix this?
P.S.: I'm working on a windows server via a RDP session, maybe that contributes to the problem.
The following worked for me.
Under the Windows menu, save the desired layout with "Save Window Layout". I named mine "Debug". This might have something to do with the old layout names.
Stop debug mode if your in it, and apply that layout with "Apply Window Layout".
Start debug mode.
My un-docked windows flash as if they are resizing, yet stay where I had them in the saved layout.
I have a Windows shell extension that uses IShellIconOverlayIdentifier interface to display overlay icons on files and folders. My extension is a little like TortoiseCVS or TortoiseSVN.
Sometimes I need to make Windows Explorer redraw all it's icons. To do this, I call SHChangeNotify like this:
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, NULL, NULL)
This refreshes the desktop and right hand pane of any open explorer windows. It doesn't refresh the folder tree on the left hand side of any Explorer windows.
So I tried sending WM_SETTINGCHANGE like this:
SendMessage(HWND_BROADCAST, WM_SETTINGCHANGE, 0, 0)
on Vista this refreshes the folder tree, but not the right hand pane.
The combination of SHChangeNotify() followed by WM_SETTINGCHANGE seems to work quite well on Vista. But I still can't refresh the folder tree on XP if it is displayed.
Does anyone have any ideas how to do this better?
Is there a better solution for XP?
Sending SHCNE_ASSOCCHANGED is a bit like clubbing Explorer over the head. It causes the whole desktop to refresh quite violently and casues any open Explorer windows to loose there scroll position. Is there anything that's a bit less violent?
Does anyone have any ideas how to do
this better?
Personally I don't know. You mention the Tortoise programs which do a similar thing, so an excellent starting point would be to have a look at what they do in their source :)
These look to be the relevant source files that handle this problem:
TortoiseCVS - ShellUtils.cpp
TortoiseSVN - ShellUpdater.cpp (username: "guest", password: "")
I note in the RebuildIcons method in each of those will:
set the shell icon size or colour depth to a temporary value
updates all the windows by broadcasting the setting change
resets the shell icon size or colour depth to the original value
updates all the windows a second time with a broadcast of the setting change
Perhaps this is part of the trick to get things working in XP.
Use spy++ to see what WM_COMMMAND message gets sent when you press F5 in windows explorer or find what menu message is used for view/refresh
Then use FindWindow to get the explorer window you want and send the WM_COMMAND recorded earlier etc message to it.
This is a fun way to control all sorts of Windows programs.
You can also send a WM_KEYDOWN message with the F5 keycode to all open explorer windows. This is a bit of a hack though.
I want to get the window handle of some controls to do some stuff with it (requiring a handle). The controls are in a different application.
Strangely enough; I found out that many controls don't have a windows handle, like the buttons in the toolbar (?) in Windows Explorer. Just try to get a handle to the Folder/Search/(etc) buttons. It just gives me 0.
So.. first question: how come that some controls have no windows handle? Aren't all controls windows, in their hearts? (Just talking about standard controls, like I would expect them in Windows Explorer, nothing customdrawn on a pane or the like.)
Which brings me to my second question: how to work with them (like using EnableWindow) if you cannot get their handle?
Many thanks for any inputs!
EDIT (ADDITIONAL INFORMATION):
Windows Explorer is just an example. I have the problem frequently - and in a different application (the one I am really interested in, a proprietary one). I have "physical" controls (since I can get an AutomationElement of those controls), but they have no windows handle. Also, I am trying to send a message (SendMessage) to get the button state, trying to find out whether it is pushed or not (it is a standard button that seems to exhibit that behaviour only through that message - at least as far as I have seen. Also, the pushed state can last a lot longer on that button than you would expect on a standard button, though the Windows Explorer buttons show a similar behaviour, acting like button-style checkboxes, though they are (push)buttons). SendMessage requires a window handle.
Does a ToolBar in some way change the behaviour of its child elements? Taking away their window handle or something similar? (Using parent handle/control id for identification??) But then how to use functions on those controls that require a windows handle?
If they don't have a handle, they're not real controls, they're just drawn to look like controls.
But of course, the toolbar buttons in Windows Explorer do have window handles, they're part of a toolbar. Use the toolbar manipulation functions to interact with them, not EnableWindow.
Or, better yet, use the documented APIs for things like search. Reverse-engineering Windows Explorer has never ended well for anyone, least of all the poor Windows Shell team, saddled with years of backwards-compatibility hacks for certain developers who thought that APIs are for everyone else. Whatever you do manage to get to work is very likely to break on the next version of Windows.
The controls you are talking about are using the ToolbarWindow32 class. If you want to interact with them then you'll need to use the toolbar control APIs/message. For example for enabling buttons you'd want to use TB_ENABLEBUTTON.
You can implement the controls yourself using GDI, OpenGL or DirectX. Try Window Detective on Mozilla Firefox and you will see that there is only one window. Controls in dialog boxes are not windows known to Windows.
On the Windows Vista taskbar, you can middle-click an icon to open a new instance of a program. In a Windows Vista explorer window address bar (the thing that shows the current file path as a bunch of clickable folders seperated by arrows,) you should be able to middle-click a folder and open a new window there. Is there anyway I could write code to modify Windows to do this?
Not an easy way. You could look into writing an Explorer BHO that subclasses the Windows Explorer window, in particular the address bar control.
Update: Should mention that while BHOs are always mentioned in the context of IE, they are also loaded by Windows Explorer, unless explicitly registered not to be.
Disclaimer: Do not write a BHO after consuming alchohol. Writing a BHO should not be done by pregnant women, small children under age of 18, and people with heart problems. Possible side effects include weight loss, weight gain, sleep deprivation, increased number of SO questions, depression, vomiting, nausea, can affect your work/life balance problem, and lead to severe problems with your life partner.