1. Gadgets to control windows inside of current workspace (windows of built-in terminal or windows of external processes)
2. Active window
3. Difference between acitive window and window that has keyboard focus
For the purposes of the terminal automation, user can can create (on the LauncherTree) and launch (from the LauncherTree) three different types of automation gadgets. Those gadgets are launched into particular terminal or into the other window in the current workspace. Simplest is COMMAND, it just pastes predefined string into terminal. (I-)SCRIPT is a text file that contains several lines that are pasted into terminal one by one, making sure that remote host finished processing of previous line before the new line is pasted at the command prompt. (I-)PLUGIN is local external child process that is created by terminal and that interacts with remote host via that terminal on behalf of the user.
Built-in Proxy32 terminal has internal support to execute COMMAND/SCRIPT/PLUGIN automation gadgets. Each terminal instance (window) has its own instance of SCRIPT processor and PLUGIN processor.
Therefore, any automation gadget is executed by particular terminal instance/window independently of other terminal windows. For example, one terminal can run SCRIPT for several hours while another terminal can execute PLUGIN for several hours and those two terminals do not interfere with each other.
When particular terminal window is running SCRIPT or PLUGIN, it is busy and will not allow user to start another COMMAND, SCRIPT or PLUGIN into the same terminal window until previous SCRIPT/PLUGIN finishes in this window.
For the windows of external processes (PuTTY, MinTTY, Notepad, Firefox, Jedit etc) there is no built-in support for automation gadgets (as I did not write code for those processes), so only COMMAND gadget is supported. When COMMAND is executed to the window of the external process, this window is brought to the front and it receives keyboard focus. Then COMMAND string is injected into keyboard buffer as if it was typed by the user.
Automation gadgets are executed from LauncherTree but they do not contain information as to which window they should be executed. Therefore, out of all windows in the current workspace, one window is always labelled Active. Active window is the window in the current workspace in which all launched COMMANDs/SCRIPTs/PLUGINs will try to execute. If this Active window is the window of built-in proxy32 terminal, then any one of the three types of the automation gadgets can be executed (COMMAND/SCRIPT/PLUGIN) - if terminal is not currently busy executing another SCRIPT/PLUGIN. If this Active window is the window of external process (PuTTY, MinTTY, Notepad, Firefox, Jedit etc) or window of Proxy32 built-in SCRIPT editor, then only COMMAND gadget can be executed into such window by simulation of the user keyboard input as described above.
If Active window is window of proxy32 built-in terminal or window of Proxy32 built-in SCRIPT editor, then such active window will have thick red frame to highlight it better. Active window of external process (for example, Notepad, Firefox etc) is highlighted by red label (sticker) with the word “ACTIVE”, that is placed over the top of the window titlebar. Color of the red frame (and sticker) of Active window can be changed or the frame highlighting can be completely disabled via proxy32 "Options Dialog".
User can make any window inside of the current workspace Active:
Active window should not be confused with window that has keyboard focus.
Notion of Active window is internal Proxy32 concept that labels one of the windows in the current workspace as recipient of the automation gadgets. Active status of the window does not change if user clicks on the background or on the title of the main window or if user clicks on LauncherTree, Selector or on the other window outside of proxy32.
Notion of the keyboard focus is system-wide. Only one window in the whole MS-Windows system can have keyboard focus and that window will receive keystrokes that user types from the keyboard. If user clicks on the background or on the title of the main window, keyboard focus goes to the main window even so one of the terminals in the current workspace is labelled as Active. If user clicks on the background or on the title of the Microsoft Word window, keyboard focus goes to the the Microsoft Word window even so one of the terminals in the current workspace is labelled as Active.
So, even if some window inside of Proxy32 workspace is labelled as Active, user have to click on this window to put keyboard focus into this window before attempting to type into this window manually. To launch automation gadget into particular terminal user only have to make sure that desired terminal window is Active, but keyboard focus has no relevance in this case.
By default, after execution of automation gadget into particular window, Proxy32 will automatically move keyboard focus from LauncherTree window into the window that executed last automation gadget. This is done on purpose, so that user can type into desired window immediately after automation gadget was executed into it (without need to click into this window first). This behavior may be disabled via Proxy32 "Options Dialog".
New window becomes active at the time of its creation. This is done on purpose, so that user can type into new new window or execute command/SCRIPT/plugin into it immediately after it was created.
When window is activated by selection from the Selector Window or from the list of the windows in the current workspace, Proxy32 will automatically put keyboard focus into this window on activation. But later keyboard focus can migrate out of Active window is user clicked inside of some other window.
When COMMAND automation gadget is executed to the window of external process, this window (for example, web page with the form user about to fill in in the web-browser) may have multiple text-entry slots and each of them may receive keyboard focus. It is up to the external process to decide in which text-entry slot put keyboard focus when window is being "activated". User is responsible for moving keyboard focus to the right text-entry slot inside of the window of external process before executing COMMAND automation gadget into the window of this external process.