WindowBot™

WindowBot ™ can execute some actions whenever a window of interest appears on your Desktop.

WindowBot™ can be used for:

• Closing annoying popups: You can put away (close, minimize, put on bottom or hide) windows that you would have to click away manually every time they appear. Sometimes advertising is bullying directly into your daily work. This function will close them automatically for you. You can also let it close the message box "Network reconnecting failed" that can pop up if a server or the internet was disconnected.
  
  
• Automatically move opening windows to a specific location or center them
  
  
• Closing applications: You can let WindowBot automatically close windows or entire applications at the occasion when for example the UI is locked (Windows-Key + L). For example if you do that with your password safe program (eg. KeePass, LastPass) it will automatically enhance your safety. You can also do that in the event when somebody connects to your PC by a remote session and on other occasions.
  
  
• Changing the priority of a process that generates a window when it appears. For example, 7-Zip archiving runs or File Explorer copy/move operations can be changed to interfere less with your work. But instead of the latter, it would be better to use the File Copier in the 'File Center' anyway.
  
  
• Clicking a button or a point inside a window. For example you can click away annoying modal dialogs like "Are you sure?" or let your camera take a photo.
  
  
• Automatically bring a window that asks for a password to the top after the boot procedure. Example: You could get a required login for a network drive or an encrypted volume before Mighty Desktop's 'Resume' function is allowed to run. In this case you would like to have this window on the front, not having to dig for it behind other windows that appear when Windows is loading your Desktop. Solution: You can add a WindowBot™ task that is executed after boot just once which brings the window to the top. In this case the action ' Place Window at Top' is exactly suited.
  
  
• Executing any action you like by combining predefined commands. There are already many actions predefined in Mighty Desktop that you can use as building blocks. Read more in chapter Mighty Actions.
  
  
• Up to your imagination.
  
  

If WindowBot detects that a specified window comes into existence (or a button resp. control appears in a certain program) it will execute the action you configured. A list of arguments in the form "Name:Value" will be handed over to the action. WindowBot will at least hand over the following arguments to the action:

• Text = Status message like "Executing WindowBot entry ..."
  
• EntryName = Name in the list
  
• WindowHandle = The handle used by Windows
  
• WindowTitle = Title text of the window
  
• WindowClass = Class name of the window
  
• WindowId = Individual number of the window which was given to it by the programmer
  
• PID = Process ID number
  
• ProcessName = Name of the process that created the window. See more in the chapter Identifying Processes of ProcessBot.
  
• ProcessPathName = Pathname of the process that created the window (including folder path)
  
• ProcessPathNameOrName = This is usually 'ProcessPathName' but if that is invisible (empty or filled with whitespace) it's 'ProcessName'
  
• ProcessArguments = The arguments that were given when the process was started
  
• MatchProcessArguments = Boolean from the column 'Match Arguments' in the list
  
• ProcessIsElevated = Whether the process runs in admin mode
  
• LastExecution: The DateTime this action was executed the last time
  
• LogInfos: Boolean which tells whether the action should log some informations what it's doing (similar to 'Verbose')
  
• ... = The field 'Action Arguments' in the grid will be parsed and all the arguments will be added to the list. The syntax is the same as for commandline arguments (see chapter). Example: Point:10,20 MyArgument:30" will add two arguments 'Point' and 'MyArgument' to the list. To figure out the syntax switch to the 'Actions' tab and try out your action first there.
  

Check out the chapter Mighty Actions on how to access these arguments and insert them in the string in the column Action Arguments.

Recurrence: You can specify how often WindowBot™ should check whether a window or button (resp. control) can be found on screen and then executes the action:

• Manual: Only if you run it by pushing a button, executing a menu item or call it from commandline
  
  
• Background Checking Interval: Each time all the background checks are done, which is all 10 seconds by default
  
  
• Waiting To Resume: Periodically while waiting for the resume pattern to be fulfilled (see Suspend-Resume)
  
  
• Once After Resume: After the PC was resumed and the Resume function finished
  
  
• Once After Booting: After the PC has been booted
  
  
• Specified Interval: You can enter your own time span. There are no limits for the length of a time span. Extended timespan notations used in DateTime Calculator are supported.
  
  
• At Workstation Locking: If you go into the Windows Desktop lock screen
  

• At Workstation Unlocking: If you unlock your Windows Desktop
  
  
• At Remote Connect: If another computer connects remotely to your PC
  
  
• At Remote Disconnect: If a remote connection has been disconnected
  
  
• At Remote ControlChange: If a remote PC takes over the desktop control, or if it terminates the control
  
  
• At Logoff: If you log the current Windows user off.
  

A special paste operation is supported: You can paste a list of WindowBot™ entries from a textual XML structured definition. This is the same format that you will see when you drag or copy some entries into your text editor. If an entry is already existing it will be skipped. This allows to easily exchange WindowBot™ entries with your friends or import some from websites. In the future there is planned to have a page on our Website that lists some new cool WindowBot™ entries. Please send us your cool stuff by the feedback function in the About tab. We will then place it on that web page.

Also don't be surprised if some windows have a special behavior. If you try to close them they will just go to the minimized state or get invisible. While that doesn't pose much of a problem (you can just change the action in WindowBot to 'Minimize') some windows produce really strange reactions. The following ones are those that are already known (please send us an info if you found more):

• Avira Antivirus Software: If you close windows of the process 'ipmgui.exe' be sure to hide this window or put it to the bottom (it resists closing):
  
  Title "", Id 0, Class "AvIPMDialog", Pos:650,438 Size:300,325 Visibility:Visible
  
  This window is technically visible and has a nonzero size but it's completely transparent and still strangely takes clicks (the programmer should have made it click-transparent). So, if you don't put away this window you will experience the effect that a part of the Windows Desktop is not reacting on a click. To identify the cause of such things you can switch to the tab Window List and use the button "Select by Pointing". It will discover the invisible window and you will be able to change it to hidden.

Window Identification

Please note that the unique identification of a window (column 'Window Title') is a difficult task. The window title can change frequently, e.g. because it contains the name of a document or a counter. Furthermore, even window class names can change, if for example, a random number such as a GUID is appended. Furthermore, the path of the executable file can contain a version number. To solve this, Mighty Desktop has a pattern matching system with the characters '*' (which means any string) and '? (any character). For more complicated cases, Regular Expressions can also be specified for matching in the Process Variations tab. For how to check the process properties, see the Process Identification chapter of the ProcessBot tab. But be warned that the "Main Window" reported by the process is sometimes not identical to the currently running main window of the process. Maybe it is only stored once, the first window that a process creates.

Notes:

• Known changing stuff of known apps is already automatically removed for saving the state and allowing a successful comparison. For example the passage "(Running)" is removed from Visual Studio main windows so that a non-running solution will match a running one.
  
  
• Go to Window: Tries to find the window of a process according to the current entry and then shows this process in the process list. If nothing matches, it analyzes what does not match and displays it in the Log panel. Helpful in case of non-matching properties. For more see section "Process identification" in chapter "ProcessBot".
  
  
• Go to Process: Tries to find a process with the process parameters of the current entry without checking the window properties and then switches to the Process List and highlights the process. If nothing matches, it analyzes what doesn't match and displays it in the Log panel. A good diagnostic tool. For more see section Process Identification of ProcessBot.
  
  
• WindowBot™ can react not only to program windows, but practically to any control elements, e.g. buttons, dialogs, etc., since these are technically also "windows".
  
  
• Note that the action "Place Window at Top" is different from "Activate Window". It has the useful feature to keep the current input focus (cursor) where it is, while "Activate Window" moves the focus over to the activated window.
  
  
• It's usually the best approach to apply the 'Close' or 'Minimize' action to the topmost window if you are working with a hierarchy of windows that are nested inside each other. Switch to the 'Window List' tab and use the [Go To Parent] button to jump up the hierarchy until you are at the topmost.
  
  
• If an action doesn't get executed, select it in the grid and try the buttons "Go to Window" and "Go to Process". If that fails some property of the window could have changed. These buttons contain some extended logic to find the cause and report it. Applying patterns for the changing part can solve the problem.
  
  
• Window oriented actions like 'Close Window' try to find a single window that matches all the specified arguments. For security reasons they will only run if exactly one window matches. If there are multiple windows with the same criteria they will issue an error message. But if an argument "WindowHandle" is in the list of arguments they will ignore the other properties and take the window if it can be found.
  
  
• WindowBot™ works only on open windows, never on minimized or invisible ones. If you want to react when a window does not exist or no longer exists, please take a look at the tab Permanent Apps.
  
  

Concrete settings (alphabetical)

<?xml version="1.0" encoding="utf-8"?>
<WindowAction xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<UserdefinedName>7-ZIP to low priority</UserdefinedName>
<WindowDescriptor>
<Title>*% Compressing *</Title>
<Id>0</Id>
<ClassName>#32770</ClassName>
<ProcessPathName>C:\Program Files\7-Zip\7zG.exe</ProcessPathName>
<ProcessName>7zG.exe</ProcessName>
<ProcessArguments>§any§</ProcessArguments>
</WindowDescriptor>
<MultipleWindows>true</MultipleWindows>
<Action>Set Process Priority</Action>
<ActionArguments>ProcessPriority:Idle</ActionArguments>
<Recurrence>
<RecurrenceType>SpecifiedInterval</RecurrenceType>
<TimeSpan>1:00</TimeSpan>
</Recurrence>
</WindowAction>

You can add these to your list if needed just by pasting.