I am in the processing of Automating Virus Scan Exclusions. Since I cannot write straight to the registry, I am making a macro of sorts using PowerShell. It works pretty well, but I want to ensure that I have the focus of the window I want before I send a slew of key strokes to it.
Using the following code, I get to the VirusScan Exclusions for McAfee.
& 'C:\Program Files (x86)\McAfee\VirusScan Enterprise\mcconsol.exe'
Start-Sleep 5
[void] [System.Reflection.Assembly]::LoadWithPartialName("'Microsoft.VisualBasic")
[Microsoft.VisualBasic.Interaction]::AppActivate("VirusScan Console")
Start-Sleep -m 500
[void] [System.Reflection.Assembly]::LoadWithPartialName("'System.Windows.Forms")
[System.Windows.Forms.SendKeys]::SendWait("{DOWN}{DOWN}{DOWN}%{ENTER}")
start-sleep -m 500
#[Microsoft.VisualBasic.Interaction]::AppActivate("On-Access Scan Properties")
[System.Windows.Forms.SendKeys]::SendWait("{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{DOWN}{TAB}{TAB}{TAB}{RIGHT}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{TAB}{RIGHT}%E")
start-sleep -m 750
However, there is a chance that focus could not be on the correct window.
Child windows
'On-Access Scan Properties' and then 'Set Exclusions' (as a child of 'On-Access Scan Properties') appear.
Questions:
1) What code can I use to set the focus to a particular subwindow (by title)?
2) What code can I use to test that the window is in fact the focus?
Basically I use and RDP manager to connect to a bunch of different machines. I want to set this script off and forget it. In order to do that, I have to ensure that the proper windows are in focus. It doesn't work well when I am switching between RDP connections.
Related
I wrote a simple script to track keys being pressed and released as shown below:
$j = 0
while($j -lt 10000){
$PressedKey = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown,IncludeKeyUp")
$PressedKey
continue
}
When I run it and start pressing keys, it works. However when I switch to a different Instance or Window and start pressing keys, it stops giving an output. I assume this is because it stops tracking the keystrokes, can't produce an output, or both. Does anyone know any good alternatives to ReadKey() to how to make it track keystrokes on other Windows and/or Instances
I believe this is PowerShell 7
thx.
The object $Host refers to the current PowerShell console host. Therefore, connecting to the ReadKey() method will only return the current PowerShell host keystrokes, and that is the point of the ReadKey() method, return the current host's keystrokes so that other functions (e.g. PSReadline) can act on them.
If you want to globally respond to keystrokes across applications, I personally recommend AutoHotKey. It is fairly easy to create a script that will detect a key combination and perform an action. It is fast and easy to use and I have dozens of key combinations that I have scripted and use every day.
It is possible to create PowerShell scripts that globally hook into keyboard keystrokes and respond to events, but this is beyond the scope of a SO post.
I am trying to catch the events when the windows on my system are created and destroyed.
However, I am facing some strange results:
Everythink works fine with some windows/applications, but with certain windows/applications the events I receive seem all mixed up.
For exemple, everything seems fine with Notepad.exe, but not with Calc.exe.
With Calc.exe, when I open it I get 2 x HSHELL_WINDOWCREATED and 1 x HSHELL_WINDOWDESTROYED.
When I close it I get 4 x HSHELL_WINDOWDESTROYED.
I am lost!
Here is in detail the result I get from the "ShellHook Messages" script (https://www.autohotkey.com/board/topic/32628-tool-shellhook-messages/):
(I just added the "Title" column. The titles are in French.)
I get the same stange behaviours when I track the events with :
the script "WinHook" (https://www.autohotkey.com/boards/viewtopic.php?f=6&t=59149)
or with a more direct approach (https://www.autohotkey.com/board/topic/80644-how-to-hook-on-to-shell-to-receive-its-messages/)
This is the script I use to open my windows:
#SingleInstance Force
#NoEnv
^j::
run notepad.exe
return
^k::
run calc.exe
return
I have Windows 10 Pro 21H2 19044.1645.
Any help appreciated!
Thank you!
Does anybody know if it is possible to uninstall software through PowerShell if it prompts for user input? I have multiple scripts that can uninstall just about anything, except for the one software that I need it to uninstall. I'm specifically trying to uninstall PDFForge toolbar which is installed when downloading PDFCreator.
None of the scripts that I've written fail, they just hang when run, I believe because the uninstall process is asking for user input to proceed.
PowerShell isn't going to interact with the prompts... you can't just tell it to click "Next" in an executable because it can't see it.
You can send keys to it though. You're really just using COM objects.
So, first, get your process ID by setting a variable that contains an array, the data for which is defined by the name of your process. Let's say your process is called, "Uninstall" and the process is ALREADY RUNNING:
$a = Get-Process | ?{$_.Name -eq "Uninstall"}
Start the COM:
$wshell = New-Object -ComObject wscript.shell;
Bring the uninstallation program with this process ID to the front so we can send it keystrokes:
$wshell.AppActivate($a.id)
Give it a few seconds to bring that window forward. I chose 5, but if your machine isn't stressed, 2 is probably enough:
Start-Sleep 5
Now start telling it what keys you want to send. The syntax here is this: whatever is in the () is what will be sent. The position in the single-quote is the keystroke to send, after the comma is how long you want it to wait before proceeding. Assuming the first screen is "Next" you can send your first command by telling PowerShell to send the ENTER key and wait 5 seconds:
$wshell.SendKeys('~',5)
The wait function is optional, but for your purposes, you're definitely going to want it. (If you don't want it $wshell.SendKeys('~') would send the ENTER key and immediately move to the next command.)
Walk through the uninstallation yourself manually, using all keystrokes, and for any keystroke you send, pay attention to how long it takes before the next part of uninstallation is loaded, and wait longer than that with your script (e.g. if it processes your ENTER key instantaneously, I'd have it wait 3 or 5 seconds before it sends the next command. If it takes 5 seconds to load, I'd tell it to wait 10 seconds before sending the next command).
Letters are letters, and numbers are numbers. Most non-commands are just assigned to their keys (meaning if you want to type "K" your command would just be $wshell.SendKeys('K')) You can get the rundown for the specific keys here: https://msdn.microsoft.com/en-us/library/office/aa202943(v=office.10).aspx.
I created an AHK macro for a colleague. I have Windows 8; she has Windows 7. She has two "pending work" folders, one for documents and the other for audio files. The (text) file names in the documents folder correspond to the file names in the audio folder. So, for example, if there is an audio file called abc123.mp3 in the audio folder, there will be a file named abc123.txt in the documents folder.
As she opens the audio file in her transcription (media player) app, as part of that process, I want to have an AHK macro automatically open the matching text file (in Word).
I created an AHK macro that picks up from the point of her selecting the file to open from her transcription app. At the point where she selects the file, she invokes the AHK shortcut, which then toggles the rename feature (F2), copies the text to the clipboard (Ctrl+C), opens the file (Alt+O), and then uses the clipboard info (along with path info) to open the appropriate text file in Word.
It's working PERFECTLY on my system. However, when I logged into her system earlier today to demo the macros, the macro would not work. It works to a point - it will rename the file, copy the name of the file, and open the audio file, and file name is in the clipboard. But that's where it dies, with no error message. During troubleshooting, I tried isolating the macro down to one command - to simply open (fixed name) file in WinWord.exe, but that doesn't work, either.
I have been unable to find any research related to this issue. I know there are numerous ways to accomplish this task, but my AHK scripting skills and my free time are limited, so I went with what I knew I could accomplish quickly. I am open to suggestions for how to troubleshoot or tweak this macro to get it working on her system. It's hard to troubleshoot when it works on mine!
NumpadEnter::
Send {F2}{Sleep 100}
Clipboard=
Send ^c
Send {Sleep 100}!o{Sleep 100}
Run, WinWord.exe "C:\DocFiles\"%Clipboard%.txt
Return
Just a guess, but I believe you wanted Sleep command and not a Sleep Key? Be sure that you are using the Latest Version of AutoHotkey you can download it from www.ahkscript.org
NumpadEnter::
Send {F2}
Sleep, 100
Clipboard=
Send, ^c
Run, WinWord.exe "C:\DocFiles\"%Clipboard%.txt
Sleep 100
Send, ^o
Sleep 100
Send, ^v
Sleep 100
Send, !o
Return
Edit:
In the script you posted, you are telling the computer to Send a Sleep Key by placing brackets around the word Sleep. Like so {Sleep}
Furthermore, you are also telling your script to not just Send one key... you are telling it to Send the Sleep Key 100 times by placing the number 100 in the brackets, separated by a space, with the named key. Like so: {Sleep 100}
I fail to see how you would want to have your script simulate 100 Sleep key presses?
What I posted above uses the Sleep Command which delays the script in milliseconds. I believe this is truly what you want.
Quick summary of question: In Windows 7, using Powershell or a little C#, how can we tell if a custom theme is going to leave a single image or do a slideshow in the background?
(Related questions but not quite the same and not answered:
How to resume Windows 7 slideshow after restoring default wallpaper (not answered / separate issue)
https://stackoverflow.com/questions/10556820/programatically-enable-windows-7-desktop-slideshow (not answered / separate issue)
How can I detect wallpaper changing as a result of the Windows 7 slideshow? (answers don't work for win 7 / separate issue)
Related resource, but didn't help:
http://www.heckler.com.br/blog/2011/03/29/desktop-background-slideshow-in-windows-home-basic-with-powershell/
)
The question is pretty much what it sounds like, and I am not sure why it is having so much trouble.
In Win8 I can use technique's based on Andy's post ( Powershell script from shortcut to change desktop ) to get the source image. From there and from what I can tell, slideshow always ends up in TranscodedWallpaper.jpg, and as soon as you drop to a single image it switches to the name of the image. So a bit round-about, but I can tell if slideshow is on
In Win7 I can check WallpaperSource
Get-ItemProperty 'HKCU:\Software\Microsoft\Internet Explorer\Desktop\General' WallpaperSource
but it only gives me the current image if there is a slideshow, and if we are using a 'Custom.theme' then
Get-ItemProperty -path 'HKCU:Control Panel\Desktop' -name 'Wallpaper'
returns TranscodedWallpaper.jpg each time, even if there is only one image left in there and no time interval. (Regardless if I use the above command or Andy's script)
I've tried running Process Monitor to figure out what windows does, and it plays a little in 'C:\Windows\Globalization\MCT\MCT-US\Wallpaper\desktop.ini' but it doesn't seem to leave any marks I can use. It helped me find
Get-ItemProperty -path 'HKCU:Control Panel\Personalization\Desktop Slideshow'
which has a Shuffle and Interval field, but neither changes when we are in a Custom theme - single image vs a Custom theme - slideshow.
I am sure I am missing very obvious (being new to playing on this end of Windows and Powershell).. any thoughts?
Took a while but I figured it out (or figured out a solution). If anyone else runs across this, Win 7 has an ini file:
C:\Users\[...]\AppData\Roaming\Microsoft\Windows\Themes\slideshow.ini
When there is only one picture in the 'slideshow' this file becomes empty, so using .WallpaperSource is the correct background image. When there are multiple images in a slideshow then this file has content (the information on transitioning the background) so even if .WallpaperSource seems like the right image, it will likely change over time based on the interval.
In short, from what I can see (and until I run across the situation that breaks this rule and I go back to the drawing board), to see if you have a slideshow you:
$doesFileExist = Test-Path $PATH_TO_THE_INI_FILE
if ($doesFileExist){
$iniContent = Get_Content $PATH_TO_THE_INI_FILE
if ($iniContent){
# This was a slideshow
}
else {
# This does not seem to be a slideshow
}
}
(This is of course only for the build in Windows 7 functionality, no idea how it would react to all the custom code and apps out there). And the Win 8 solution is up in the initial question