Automate Dual Monitor Setup In Vista - powershell

I use a laptop as my primary workstation. Sometimes I work alone on it, but a significant portion of the time, I'm at my office desk and I hook up an external monitor to increase my workspace.
Every time I perform this action, I click the same dialog boxes in Windows Vista to setup the dual screen and position the window. It seems like a repeatable task that I could automate.
I'd like to be able to plug in my monitor cable, double click a program and have it automatically configure the monitor.
What type of program could do this? I haven't found much online that relates. I'm thinking of trying an autohotkey script, or the Windows Accessibility API with PowerShell. Has this problem already been solved?
Clarification: I'm specifically looking to automate the steps I use with my mouse that invoke the base functionality in Windows Vista.
Right click on desktop
Select Personalize in context menu
Click display settings
Click monitor #2, then click checkbox to "Extend desktop to this monitor"
Click and drag monitor #2 to the left of monitor #1
Click OK to close the dialog
Click Yes in the subsequent pop up to accept these monitor settings
Update: Windows 7 does this automatically
I just upgraded to Windows 7 and it remembered my dual monitor settings. I set them once at work as listed above, then unplugged and worked at home over the weekend. I came in on Monday morning, booted up, plugged in and whammo! It just worked. Thanks Windows 7!

I haven't seen an existing utility that does this but it would be pretty easy to write one using the Win32 APIs. Via this page, EnumDisplayDevices gets a list of display devices, EnumDisplaySettingsEx gets the current settings and ChangeDisplaySettingsEx will make the changes.
The DEVMODE.dmPosition field should contain the virtual coordinates of the top left corner of the display, with the primary monitor always being (0,0) and the others relative to that.
The tool would need two modes, the first saves the current settings to a config file, and the second applies the settings from the config. I'd store/retrieve only the display device index, name, and each of the DEVMODE.dm* fields mentioned in the ChangeDisplaySettingsEx docs. A text-based config allows for hand-edits.

Try UltraMon for excellent dual monitor support. I've been using it for years on a number of different laptops and desktops and it works great. I've only used XP so I am not sure how it works with Vista.

My Leovo T60p does this automatically without any special steps. Try upgrading your video drivers, and check the manufacturer's site for any utilities that can do that.

If you have windows vista or 7 you could hit the windows_key + P. You have a bunch of options to select including extend

I believe Ultramon would in fact work. In the right-click menu on the Ultramon icon in the systray there is a "disable/enable secondary" command.
I think you could simply:
plug in the second monitor
select "enable secondary"

Here I am, three years later, answering my own question! Yay!!!
This is easily scripted with http://www.autohotkey.com
Here's an example script for swapping between one monitor and two monitors with Windows+1 and Windows+2. AutoHotKey also allows for click and drag behavior that would be needed to swap the position of the second monitor.
#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
#Warn ; Recommended for catching common errors.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.
#1::
Send {LWin}
WinWaitActive Start menu
Send Adjust Screen Resolution
Send {enter}
WinWaitActive Screen Resolution
ControlClick ComboBox3
Send {PgDn}
Send {Up} ; Select "Show desktop only on 1"
Send {enter}
Sleep 3000 ; workaround - cannot select accept/revert window?
Send {left}
Send {enter} ; accept changes
Return
#2::
Send {LWin}
WinWaitActive Start menu
Send Adjust Screen Resolution
Send {enter}
WinWaitActive Screen Resolution
ControlClick ComboBox3
Send {PgDn}
Send {Up}
Send {Up} ; Select "Extend these displays"
Send {enter}
Sleep 3000 ; workaround - cannot select accept/revert window?
Send {left}
Send {enter} ; accept changes
Return

Related

AHK for Save Dialog: Navigate to desktop and jump to field filename

I was using this Autohotkey script for a while:
; Windows Explorer Save Dialog
; hitting CTRL D goes to address bar, jumps to full desktop path, then goes to filename for the user to override
#IfWinActive ahk_class #32770
^D::
Send !D
String := "%UserProfile%\Desktop"
SendRaw %String%
Send {ENTER}
Send !D
return
#IfWinActive
It stopped working. Probably a Windows 10 update changed something in the file save dialog.
Now using the script above (hitting CTRL+D) still opens the desktop location, but goes to the top right "Desktop Search" (instead of the filename).
Also changing the last Send !D to Send !N did not help.
Also Send {TAB} does not help, Windows ignores it. The focus seems to be stuck to the Search field.
After the discussion in comments, I was actually able to reproduce the issue you're encountering and found the issue.
The Alt+N hotkey in the save file dialog to switch focus to file name field indeed doesn't seem to work if the focused control never left any of the text input controls. By setting the focused control at least once to something other than one of the text input controls, then the Alt+N hotkey seems to work as expected.
Ok, so here's the working code.
^d::
ControlFocus, DirectUIHWND2, A
SendInput, % "!d%userprofile%\Desktop{enter}!n"
return
So first we're focusing the DirectUIHWND2 control, could've used an other control in the save file dialog as well, doesn't matter which one we use.
And if you don't know how to figure out windows' controls, one easy way is to use "Window Spy". It's a neat little AHK script that comes with every AHK installation.
You'll find it from your AHK install directory.
Should be called C:\Program Files\AutoHotkey\WindowSpy.ahk. Or if you have an older AHK installation, it may also be a compiled script file named AU3_Spy.exe (or something like that, I forget)
And the A parameter in the ControlFocus command means the active window.
And then I used just one send command. No need to use multiple send commands, or create some variable, as you do in your code.
And also used !d and !n instead of !D and !N.
Don't use capital letters in send commands, unless you actually want them.
!D and !N actually send Ctrl+Shift+D and Ctrl+Shift+N, instead of Alt+D and Alt+N, which is what I assume you actually were after.
Also, used SendInput instead of just Send. SendInput is the preferred method due to it being faster and more reliable (more about this from the documentation)
Though, one concern I have, is maybe it could even be too fast. Seems work fine for me every single time, but if you were to have trouble, you can maybe split it up to multiple commands, adding a bit of Sleep in between. Or maybe could even switch back to Send and use SetKeyDelay.
Another approach for this, could be with using control set -commands.
E.g. first focusing a control, as I did in my code, and then using e.g ControlSetText.

How to immunise my antiprocrastination script against logout and shutdown?

I'm trying to build a script in autohotkey which will make it annoying for myself and fellow users of the flashcard program Anki from quitting midway through a study session.
So far I have written the following
InputBox, TimeMin, ATTENTION, Enter how long would you like to commit to answering flashcards in minutes.
TimeMili:=TimeMin*60*1000
SetTimer, Meh, %TimeMili%
a:=0
While a < 1
{
IfWinActive User 1 - Anki
{
MouseMove,1298, 981
WinKill Task Manager
WinMaximize User 1 - Anki
}
Else
{
WinKill Task Manager
IfWinExist User 1 - Anki
{
WinActivate User 1 - Anki
MouseMove,1298, 981
}
}
}
return
!F4::
MouseMove 350,350
return
Meh:
MsgBox WELL DONE U R NOW FREE
SetTimer,,OFF
a:=10
Return
Lwin::
Return
Rwin::
Return
This script disables alt + f4, kills taskmanager, maximizes the anki window whenver it is minimized and prevents the mouse coming near the red exit button on the outside of the programs window for a user-defined number of minutes. As anki can be navigated without using the mouse, this selectively impedes procrastinating actions without impeding studying.
The script works pretty well, but it can be overcome by restarting the computer or doing a slow logout via control alt delete (win + L doesn't terminate script). Control alt delete is very hard to disable on modern windows builds, likely as a malware prevention safeguard.
My proposed solution is to have the script perform some annoying action (e.g. deleting all desktop shortcuts) when activated, and to undo that same action when the user-defined time period terminates. I believe this would leave the annoying action unfixed if the user logs out/shuts down/restarts/slow log offs.
I've considered using the script to create another annoying script in the startup folder, but this can be circumvented by just logging out rather than restarting/shutting down.
Renaming/deleting keyboard shortcuts is only annoying if the user has a lot of keyboard shortcuts.
Creating a ton of text files on the desktop and other folders is too easy to reverse and can just be ignored by the user until they have finished procreastinating
Disabling the internet would be good, but it would still leave offline distractions (e.g. video games) available.
How best to go about designing such an action that will temporarilly disable a PC that is trivial and reliable, but timeconsuming and boring to undo?
While your AutoHotkey solution is a clever way to dissuade people from exiting out of the program, you will never get a true 100% rock solid solution for the following reason: you are logging in with a user that is allowed to do stuff. If you can do stuff, you and others will figure out a clever way around to do it, and no, as amazing as AutoHotkey is, it can't disable the unplugging of a power cord.
On the other hand, yes, you can make the penalties for circumventing the protections increasingly painful (up to the penultimate format c: nuclear option, which I would garner guarantees 99% compliance), but you will always start to run into issues, and still you won't get compliance.
The better solution is to use features that are baked into Windows via Group/Local Security Policies that will limit things. By using a special user with locked down privileges, they physically won't be able to do things because they can't (for ex. you can disable the start menu, power options, sites, etc.).
You really want to lock things down to a single app? Well Windows has a special Kiosk Mode where you literally can -only- have one app running, and you can't get out of it no matter what. There are dozens of special Kiosk Policies that can be applied from removing sign out options from Ctrl-Alt-Delete to Removing Task Manager.

need to close Modal Dialog Box on Windows 10 IoT Embedded system

On an embedded system, some software that we want to run will have a 'modal Dialog box' pop up informing of an error, and the software waits for the user to press [OK] (it was originally designed to not be used on an embedded system).
We want a windows setting that will automatically address the windows of this type.
To do that on a previous iteration, we would change the register EnableDefaultReply on Windows 7
HKLM\System\CurrentControlSet\Control\Error Message Instrument:
REG_DWORD EnableDefaultReply
However, that doesn't seem available on Windows 10 IoT Embedded.
We can potentially just automate a click when that window pops up, but we'd prefer to do the Windows 10 equivalent if there exists one.
Thank you.

Autohotkey sometimes stuck

Prehistory:
Some time ago Skype has assigned Ctrl+R hotkey to make a new call. This setting can't be disabled.
Sometimes I confuse browser window with Skype window and made a call to many people instead of refreshing browser window (I need to refresh browser window very often because of profession).
So I made a script to prevent sending Ctrl+R hotkey to Skype window, it works perfect, but sometimes I can't send Ctrl+R anywhere, not only Skype window.
Code:
;#NoTrayIcon
$^r::
WinGetClass, class, A
if (class != "TConversationForm")
Send ^r
return
Compiled binary: http://random.net.ua/SkypePreventHotkey.exe
Autohotkey version: 1.1.14.03
I have two improvements:
Use #If(...) for context-sensitive hotkeys whenever possible. In my experience, #If is more reliable due to various reasons. Also, you won't have to worry about non-affected windows (e.g. by deciding what to send); in fact, I believe that non-affected windows receive the original native keystrokes if the #If... condition comes up false.
AHK_L has a cool window selector called ahk_exe which lets you identify windows by their process name, rather than their class/title. It's possible that different windows of the same program have different class names, e.g. Windows Media Player in minimized/maximized mode. Possibly, Skype has that, too. That's why for more complex applications, it is often reasonable to identify by process name.
Mixing these suggestions into a solution, we get this brief piece of code:
; I hope it's skype.exe ;)
#IfWinActive ahk_exe skype.exe
^r::return
Instead of programmatically saying "If the active window isn't Skype, we send CTRL + R", we're now saying "If the window is Skype, we do nothing".
You could try something like
#InstallKeybdHook
SendMode, Input ; <---typically more reliable than send play mode
~$*^r:: ;<--- ~ means pass command to machine * means fire regardless of other hotkey modifiers.
Send, {Blind}{Ctrl Down}
Send, {R}
Send, {Ctrl Up}
return
I use a program called ACT! for my database. Whenever I script hotkeys it like to be sent commands like this vs. what you initially had (not that it was wrong).
If that doesn't work you could try adding: Sleep, 50 between each send (produces a delay) to see if that works. If so, you can cut each delay by 1/2 until it stops working again.
-islanq
Another solution using Autohotkey
#IfWinActive ahk_class tSkMainForm ;Skype
;prevent call
^r::
#IfWinActive

AutoHotkey Win+X Power Users Menu

Anyway to get AutoHotkey to pop the Power Users Menu in Windows 8.1? Typically accessed via Win+X. I can get AHK to perform other Windows key based key combinations, such as Win+D, but the Win+X refuses. I have several other AHK scripts that work fine, all UAC issues have been eliminated. I have tried 'Send, {LWin Down} x {LWin Up}', 'Send, #x', changing SendMode to all various modes had no effect. Running the AHK script as Admin had no effect, not surprisingly since I am running as Administrator and I have UAC turned completely off.
You may ask why I want to do this. The reason is I want access to the 'Shutdown or sign out' menu, so I can trigger either restart or shutdown. This is so I can use an AHK to trigger my machine to restart or shutdown (laptop). I am doing this, because what I had been using previous to Win 8.1 stopped working, which was was, for example to shut down, 'Shutdown, 9'. The computer shuts down, but then starts back up, totally strange. When I use the Win+X menu, or Start8 (highly recommended) it works fine, and stays off. I even tried skipping AHK and was via my MS keyboard able to trigger a command-line one liner of 'Shutdown -s -f -t 00' which behaves the same as the AHKs attempt at shutting my computer down. And to review, the Win+X and Start8 shutdown options work fine.
So far this is WAY more work than it should be to trigger a shutdown from a button on my keyboard!
Any help is much appreciated.
EDIT: Example code was requested, please find the AutoHotkey Script shown below, as described the Power Users Menu does not appear.
#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
SendMode Play ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.
MsgBox, 4097, , ---------- The system will restart in 5 seconds. ----------, 5
IfMsgBox Timeout
{
;Shutdown will continue
}
else IfMsgBox Cancel
{
MsgBox Shutdown canceled.
return
}
;Does not work
;Send {LWin Down} x {LWin Up}
;Does not work
Send, #x
In case anyone else is looking for a solution to this problem, you have to set focus to the Windows taskbar before sending the keys, like this:
WinActivate, ahk_class Shell_TrayWnd
Send, #x
Maybe there is some other program that uses win+X. If another program assigns it's hotkey after your script runs, it is possible that it can hijack the hotkey.
Also, I don't know about windows 8, but in XP you could assign a hotkey to a shortcut, and there isn't any way to figure out which shortcut it belongs to. I found this out the hard way when I installed a certaing program and that app's installer set a hotkey to the shortcut - I couldn't get it to go away. I finally tracked it down.
Could you have a similar issue?
Also, if you use this, does it work? It is a good test for you.
#x::
msgbox, Hey, Bob!
return
If that works, then it may be an issue with whether win+X can be (or is being) accepted by the active program.