How to set a sound notification when a script is executed in window "run" (Process finished with exit code 0)? I would like to see a notification Pycharm in Windows when the program window is minimized.
Related
I want a cygwin shell script to create a Windows notification (one of those events you see in the lower right-hand corner). When you click on the notification, I want it to bring another application into focus.
Here's how I'll use this: from the command line, I run tests. When they finish, I want to be notified with the notification. If I click on that notification, I want cygwin to go back into focus so I can decide what to do next.
Okay this was a huge pain to figure out, and even still, this solution is far from ideal -- but it does work so it's worth writing down.
It's not hard to create a notification. It's not hard to focus an application. But it is hard to create a notification that focuses a window when clicked.
Here is a script:
set -ex
notification_exit_code=0 # default value, exited successfully
# create a notification that says "Build Done". When notifu64 exits, it's exit code tells why it exited (see below)
notifu64.exe /i 'C:\\cygwin64\\Cygwin-Terminal.ico' /t info /p "Build Done" /m "Build Done" || notification_exit_code=$?
# these are some of the ways the notification could have exited
user_clicked_on_notification=3
notification_timeout=4
user_clicked_on_notification_icon=7
if [[ "$notification_exit_code" -eq "$user_clicked_on_notification" ]] || [[ "$notification_exit_code" -eq "$user_clicked_on_notification_icon" ]]
then
# The order of the steps is very important or else the window will remain in the background. I figured out these steps from here: https://stackoverflow.com/a/59819671/61624
nircmd win activate process mintty.exe
# I'm not sure why, but "activate" resizes the window. This puts it back the way it always is on my computer: maximized
nircmd win max process mintty.exe
nircmd win settopmost process mintty.exe 1
nircmd win settopmost process mintty.exe 0
nircmd win focus process mintty.exe
# This is 99% of the way there. The problem is the window still doesn't have focus, even though it brings it to the front. It's the ShellExperienceHost.exe that maintains it, and I can't figure out how to stop that from happening. I have to manually click on the window to give it focus
# And here's the workaround I wish I didn't have to do: Because the window is going to be full-sized, by moving the mouse up, I know with certainty that I won't be clicking on the taskbar (because it's docked on the bottom of my screen).
nircmd sendmouse move 0 -1000
# Now I click, to bring the window I've switched to into focus.
nircmd sendmouse left click
fi
if [[ "$notification_exit_code" -eq "$notification_timeout" ]]
then
# this makes the taskbar icon highlighted to remind me that the build is done even if I don't want to look at it immediately
nircmd win flash process mintty.exe
fi
notifu64.exe is a commandline tool that can create windows notifications.
nircmd is a commandline tool that can control various aspects of the Windows operating system. In this script, I use it to control application windows.
I am using a script that:
Launches Thunderbird
Creates a new message
Minimizes the message box
Copies the path to the selected folder
How to activate a minimized Thunderbird message box, knowing its Title?
The code below does not work:
Set WshShell = CreateObject("WScript.Shell")
Set WshExec = WshShell.Exec("""C:\Program Files (x86)\Mozilla Thunderbird\thunderbird.exe""")
WScript.Sleep 2000
WshShell.SendKeys("^n")
WScript.Sleep 500
PID = WshShell.AppActivate(WshExec.ProcessID)
WshShell.Run("notepad")
If PID Then
WshShell.SendKeys("^k")
Else
MsgBox "Nothing!"
End If
VBS's AppActivate wraps the API's SetForegroundWindow. Your program MUST comply with one of the following rules to set the active window. Note the standard lockout time is 2 seconds - which is where most people get caught. Note VBScript has no user interface so cannot be the foreground window - you have 2 seconds to set windows after your program starts.
From https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow
SetForegroundWindow
Remarks
The foreground window is the window at the top of the Z order. It is
the window that the user is working with. In a preemptive multitasking
environment, you should generally let the user control which window is
the foreground window.
Windows 98/Me, Windows 2000/XP: The system restricts which processes
can set the foreground window. A process can set the foreground window
only if one of the following conditions is true:
The process is the foreground process.
The process was started by the foreground process.
The process received the last input event.
There is no foreground process.
The foreground process is being debugged.
The foreground is not locked (see LockSetForegroundWindow).
The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
Windows 2000/XP: No menus are active.
With this change, an application cannot force a window to the
foreground while the user is working with another window. Instead,
SetForegroundWindow will activate the window (see SetActiveWindow) and
call the FlashWindowEx function to notify the user.
I build a fullscreen GUI application for Windows (using LabVIEW but the language should not matter much) that should start with Windows.
I want it to be fullscreen (hiding the Windows taskbar), so I set the window bounds to the screen's resolution.
When I manually launch the exe from explorer, the window hides correctly the taskbar.
But when I launch it from a scheduled task at Windows logon, it is behind the taskbar, until I click on the application. Same thing when I run the scheduled task manuallay in the task scheduler.
I tried the Win32 API function SetForegroundWindow but without success. Maybe the conditions are not met but I do not understand why, there is no other visible window.
How could I force the fullscreen of the app when it auto-starts?
If this is impossible from the application itself, an external solution to the application's code might be ok (e.g. some script running with the scheduled task), but I don't see one either.
Hey so I was having the same trouble when I scheduled a full screen application to run at login. the way I got around this was by creating a mouse click macro and scheduling it at user login with the app (had to set a 10 second delay to allow for the app to load).
It's a bit dodgy but it got it done for me
Is there a command on the Windows terminal to close the window of an active application without actually killing the task/process?
What I'm looking for is something similar to clicking the 'X' button on the application window's name bar, or hitting Alt+F4 on it.
Any help would be greatly appreciated. Thanks!
I don't want the taskkill command because it terminates the process. I don't want it to terminate, say I want to close a Skype window so that it pops up in my Notification Tray on my Taskbar.
I couldn't find a specific command on the Windows terminal to do what I wanted, but I found this VBScript code online that did the trick for me.
set shell = createobject("wscript.shell")
shell.appactivate("Skype for Business")
shell.sendkeys "%{F4}"
This simulated an Alt+F4 keypress to Skype, which effectively closed the window and sent it to my Notification Tray.
When I run the following script via CMD.EXE the display of Word is normal i.e. Maximized.
Set oWord = CreateObject("Word.Application")
oWord.Visible = True
oWord.Documents.open(sTempWordFile)
oWord.Run WScript.Arguments.item(0)
oWord.Activate
When I call the same script as Target in a shortcut .LNK file the display is always minimized!
The .LNK file target is: "%OWNERS_CORP_ROOT%\cmd\RunWord.vbs" memos
Using Windows 8.1, Office 2013. Shortcut .LNK file is set to Run 'Maximized'.
How do I make a 'Maximized' display when using the shortcut?
SetForegroundWindow Function
The SetForegroundWindow function puts the thread that created the specified window into the foreground and activates the window. Keyboard input is directed to the window, and various visual cues are changed for the user. The system assigns a slightly higher priority to the thread that created the foreground window than it does to other threads.
Syntax
BOOL SetForegroundWindow( HWND hWnd
);
Parameters
hWnd
[in] Handle to the window that should be activated and brought to the foreground.
Return Value
If the window was brought to the foreground, the return value is nonzero.
If the window was not brought to the foreground, the return value is zero.
Remarks
Windows 98/Me: The system restricts which processes can set the foreground window. A process can set the foreground window only if one of the following conditions is true:
The process is the foreground process.
The process was started by the foreground process.
The process received the last input event.
There is no foreground process.
The foreground process is being debugged.
The foreground is not locked (see LockSetForegroundWindow).
The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
Windows 2000/XP: No menus are active.
With this change, an application cannot force a window to the foreground while the user is working with another window. Instead, Foreground and Background Windows will activate the window (see SetActiveWindow) and call the function to notify the user. However, on Microsoft Windows 98 and Windows Millennium Edition (Windows Me), if a nonforeground thread calls SetForegroundWindow and passes the handle of a window that was not created by the calling thread, the window is not flashed on the taskbar. To have SetForegroundWindow behave the same as it did on Windows 95 and Microsoft Windows NT 4.0, change the foreground lock timeout value when the application is installed. This can be done from the setup or installation application with the following function call:
SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, (LPVOID)0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
This method allows SetForegroundWindow on Windows 98/Windows Me and Windows 2000/Windows XP to behave the same as Windows 95 and Windows NT 4.0, respectively, for all applications. The setup application should warn the user that this is being done so that the user isn't surprised by the changed behavior. On Windows Windows 2000 and Windows XP, the call fails unless the calling thread can change the foreground window, so this must be called from a setup or patch application. For more information, see Foreground and Background Windows.
A process that can set the foreground window can enable another process to set the foreground window by calling the AllowSetForegroundWindow function. The process specified by dwProcessId loses the ability to set the foreground window the next time the user generates input, unless the input is directed at that process, or the next time a process calls AllowSetForegroundWindow, unless that process is specified.
The foreground process can disable calls to SetForegroundWindow by calling the LockSetForegroundWindow function.
Function Information
Minimum DLL Version user32.dll
Header Declared in Winuser.h, include Windows.h
Import library User32.lib
Minimum operating systems Windows 95, Windows NT 3.1
Unicode Implemented as Unicode version.
See Also
Windows Overview, AllowSetForegroundWindow, FlashWindowEx, GetForegroundWindow, LockSetForegroundWindow, SetActiveWindow