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.
Related
I' building a webapp that reads the database based on time to check changes. When there is a change, a notification in windows displays so the user is notified.
Chrome-> Dots menu-> More settings-> Create shortcut (as window) (Roghly Translated)
The problem is that the user needs to have the webapp opened so it is working and doing the before mentioned task. I thought a solution could be to run the shorcut on startup as a service or something (maybe in the icons next to the taskbar clock). But I don't know if this is the best approach or how to do that.
That's why I'm asking for help to find the best approach and if it is the one I'm thinking, to know how could I do that.
Every time we log in to a windows account on a computer at work, the mouse layout is changed to a not-so-popular and for us impractical layout. I will not cover the technical details of why this happens and neither can I indulge why we are not able to fix the root cause. (It just is, like some people are forced to work with IE8 because sysadmins...) The point is that every time an employee logs on to a computer, they have to manually go to control panel, select the mouse options, change the mouse layout to the more common "windows aero theme" and apply this change.
I would like to write a batch script that does this action for me, and I would like to put this batch file in my startup directory so it is performed automatically. Can a batch script do this and if so, where can I find an example of the appropriate commands? You can assume each user had administrator rights.
Another challenge: our computers are thin clients, so when we "log on" all wo do is perform a remote desktop connection to our personal virtual machine on the network. We're not really booting any OS.
Any help is appreciated.
I'm a developer and a long-time Windows user with an obsession about making my system as convenient to use as possible.
Yesterday I thought about something that has always annoyed me in Windows and that I've taken for granted, and I realized that I have a better idea for how it could work, and I'm now wondering whether it's possible to tweak Windows to work like that.
The thing that annoys me is when windows steal focus. For example, I could be running an installer for some program. While it's working, I'll switch to my browser and browse, maybe entering some text into an email in my browser. Then suddenly the installer finishes and its window steals the focus. Now I'm in the middle of writing an email, so I might press a key that happens to be bound to a button on that installer, and then that button gets invoked, doing some action that I never intended to happen!
This is doubly annoying to me because I'm using a multiple-desktop program called DexPot, and when a window steals focus, it also brings itself to the desktop I'm currently on, which can be really annoying, because then I have to put it back into its original desktop.
How my ideal solution to this problem would work: Every time a window tries to steal focus, we intercept that, and don't let it. We show something like a toaster message saying "Foobar installer wants focus, press Win-Whatever to switch to it". If and when you press the key combo, it switches to the window.
The question is: Is there an easy way to tweak Windows to make this happen? I know very little about Windows programming. I do know AHK and if it's possible with that, that'd be great.
No, there isn't an easy way to add this behavior, but Windows tries to do this automatically.
In theory apps shouldn't be able to steal the foreground while you're actively using another app. Unfortunatly there are some scenarios where Windows can't tell the difference between legitimate user actions that should change the foreground and unwanted foreground-theft. The window manager generally tightens up the holes a bit with each new version of Windows, but also needs to make sure that apps can come to the foreground when the user wants them to, even if that desire is expressed indirectly.
For example, a process launched by the current foreground process can put a window into the foreground. This is necessary so that when a user launches a window from Explorer the newly launched process can open its main window. This permission only lasts until the next user input, so if an application is slow to launch and you start working on an email the app may lose its foreground permissions before it can use them.
See the SetForegroundWindow function documentation for a list of requirements for a process to be able to set a window into the foreground.
There are also apps which specifically make use of these requirements to steal the permission (by joining the foreground queue or synthsising user input to themselves), but I suspect in your installer scenario it is accidental.
I'm not sure what exactly is going on, but I suspect that the problem comes from the installer running as a service and accidentally stealing the foreground permission when it tries to launch the app on your current desktop.
It would be theoretically possible for an external process to hook into the foreground system to override this and show your confirmation toast, but it would be tricky to get right and would require significant low level code (I'd probably start with a CbtHook). It would not be possible in a scripting package like AHK (assuming you mean AutoHotKey) but would need to be native C/C++ code injected into every running process.
I want to disable / block the mouse click and keyboard typing for 6 seconds after launching a .exe file while displaying a advsplash.
Currently I manage to run a .exe file, activate the splash, block the keyboard and run a second .exe, but then, I need to restart the computer to unlock the mouse/keyboard.
Any idea on how to disable it without restarting the machine ?
This sounds like something you should never do.
If you want to do UI automation Windows already has support for that, using SendInput or keybd_event is not a good idea. Some apps steal foreground focus, this is just a fact and if that happens at the wrong time you end up sending input to the wrong window.
I have been working on windows automation and monitoring.
What exactly happens when I lock the screen of a windows machine?
I am working with Windows 7 at the moment, are there big differences to the behavior if I switch to Vista or the server versions?
Is there still a desktop that can be accessed via api's?
I know that i can still send key strokes and mouse clicks to specific windows (via ControlSend and ControlClick), but there seems to be no "desktop" itself.
Could someone shed some light on this whole thing or point me at a readable source where I could get an overview over the topic?
Basically what happens is that Windows switches to the secure desktop, makes it the current one, so input is now associated with it.
The old desktop remains where it was: all the HWNDs on the desktop are still there, and any thread attached to that desktop can still access those HWNDs, get their location, and so on. You can still send messages to windows on this desktop, so long as the thread sending the message is also on that desktop.
However, since the desktop is now inactive, it cannot receive input. GetForegroundWindow will return NULL (IIRC), and you can't use SendInput any longer, since input now belongs to [a thread on] a different desktop; no controls on that inactive desktop can receive focus.
Note that sending keypress messages to a control that doesn't have focus can sometimes cause unexpected behavior, since the app or control generally never expects to receive keyboard input without getting the focus first. (This can be problematic for controls that set up some sort of input context in WM_SETFOCUS and clear it up in WM_KILLFOCUS, for example.)
In short, the UI is still there: you can do certain queries against it, but you can no longer automate it as you could on a regular desktop by sending input, and some other functions that relate to focus or input may fail.
I'm not super familiar with AutoHotKey, but the name and description of functionality suggests that it's heavily reliant on the underlying Win32 SendInput API. This won't work at all for keyboard input when a desktop is inactive.
For a reasonable overview of how desktops work and how they relate to winstations, the locked desktop, and so on, check out the Desktop article on MSDN.
One issue that I've run into in the past with desktops and automation is: how to I leave a long-running test that's using some form of user input automation (mouse, keyboard simulation), but still lock my PC so that someone can't just walk by and interfere with it. Once you lock the PC, the desktop is inactive, and so the automation stops working. A similar issue happens if the screensaver kicks in: the desktop switches, and the automation fails.
One solution is to use two PCs: let's call them Main and Test: from Main, open a remote terminal services client onto the Test machine, and then run the automated test on the test machine, but from a terminal services client window on the Main machine. Now the cool part: you can minimize that TSC window, or even lock the Main machine (or let the screensaver kick in), and that virtual session will continue working, thinking that it is still active - it's just that nobody is paying it any attention. This is one way to create a "connected" session with an active desktop, but one that no-one can interfere with, because it's protected behind the locked desktop of the Main machine.
I don't know the details, but I believe the lock screen constitutes a separate "desktop" and maybe also a separate "window station" (as I understand it a window station is merely a container for desktops). The MSDN section on window stations should hopefully be useful: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687098%28v=vs.85%29.aspx
In order to access a desktop, you will need to use the regular windows api's from a thread that is on that desktop. SetThreadDesktop would probably be the easiest way to do that in C, as long as the desktop isn't on a different window station.
Unfortunately, this is already difficult for a regular privileged application, and using AutoHotkey complicates it even more. Since you don't have control over threads or over process initialization, you will probably have to create a new process in the other desktop (you can do this using the CreateProcess API, which appears to have a wrapper available for AHK to which you can supply a desktop name: http://www.autohotkey.com/forum/topic1952.html). Your process will need special privileges to do this; I'm not sure that even running as Administrator is enough.