16.3. Dialogs

16.3.1. Customize Perspective dialog
16.3.2. Find/Replace dialog
16.3.3. Import Squish Resource dialog
16.3.4. Manage AUTs dialog
16.3.5. New dialog
16.3.6. New Squish Test Case wizard
16.3.7. New Squish Test Data dialog
16.3.8. New Squish Test Script dialog
16.3.9. New Squish Test Suite wizard
16.3.10. Open Perspective dialog
16.3.11. Pref­er­ences dialog
16.3.12. Screenshot Verification Point dialog
16.3.13. Search dialog
16.3.14. Show View dialog
16.3.15. Squish Server Settings dialog
16.3.16. Switch to Editor dialog

16.3.1. Customize Perspective dialog

This dialog is used to customize a predefined or custom perspective—for example, customizing some of the toolbars, menus, and submenus that are visible when the perspective is shown. The dialog is invoked by clicking Window|Customize Perspective. (To change the views shown in a perspective simply close any you don't want and add new ones using the Show View action (Section 16.1.1.63).)

The Customize Perspective dialog

Use the Tool Bar Visibility tab to hide or show toolbars and individual toolbar buttons within toolbars. Similarly, use the Menu Visibility tab to hide or show menus and individual menu options within menus. The Command Groups Availability tab is for advanced users and is not documented in this manual. The Shortcuts tab can be used to add keyboard shortcut actions to submenus.

16.3.2. Find/Replace dialog

This modeless dialog is used to find and optionally replace text in the active editable window. The dialog is invoked by clicking Edit|Find and Replace or by pressing Ctrl+F.

The Find/Replace dialog

Be aware that even if you set Scope to be All the search will only be made from the current cursor position Forward (or Backward depending on the Direction setting) to the end (or start) of the file—unless you check the Wrap search checkbox. Searching is case insensitive by default but this can be changed by checking the Case sensitive checkbox. If the Regular expressions checkbox is checked the Find text can be a regex using Eclipse's regular expression syntax.

16.3.3. Import Squish Resource dialog

This dialog can be popped up by invoking the Import Test Resource action (Section 16.1.1.19). It is used to import scripts, test data, and verification points into a test case or a test suite.

The Import Squish Resource dialog

The File to Import should be chosen by clicking the Browse button and navigating to it using the Open File dialog that pops up. The file should either be a test data file in .tsv (tab-separated values format), .csv (comma-separated values format), or .xls (Microsoft® Excel™ spreadsheet format—but not .xlsx format), or a test script file (e.g., a file containing functions you want all the test suite's test cases to be able to share using the source function). If you import a test script it must use the same scripting language as that used by the test suite's test cases.

Once the file has been chosen you must tell the Squish IDE whether it is test data or a test script by setting the Import As combobox's value appropriately.

With any resource you have two choices as to its location: it can either be stored within a particular test case or it can be stored in a place that is accessible to all the test suite's test scripts. Unless the test data or test script resource really is specific to one particular test case it is almost always more convenient to store it so that it can be shared by the entire test suite. If you just want to store the data or script in the current test case check the Copy to Test Case radio button. And if you want the data or script to be shared by all the test cases check the Copy to Test Suite for sharing radio button. Then, in either case, click the Finish button.

See also the New Squish Test Data dialog (Section 16.3.7) and the New Squish Test Script dialog (Section 16.3.8).

16.3.4. Manage AUTs dialog

This dialog is used to manage the Mapped AUTs, AUT Paths, and Attachable AUTs that are registered with the squishserver. (See AUT Paths and Mapped AUTs (Section 15.3.2).) This dialog can be invoked by clicking Squish|Manage AUTs.

The Manage AUTs dialog

Any child item shown in this dialog can be removed by clicking the Remove button. To add a new Mapped AUT, AUT Path, or Attachable AUT, first click the appropriate parent item (e.g., “Mapped AUTs” if you want to add a Mapped AUT), and then click the Add button. Once you have finished with the dialog click the Close button.

It is also possible to register and unregister AUTs using Squish's command line tools; see AUT Paths and Mapped AUTs (Section 15.3.2).

(From Squish 4.2 this dialog is replaced by the Manage AUTs pane in the Squish Server Settings dialog (Section 16.3.15).)

16.3.5. New dialog

This dialog is used to import a new shared Squish test script or test data file, or to create a new test case within the current test suite, or to create a new test suite. The dialog can be invoked by clicking the main window's New toolbar button or by pressing Ctrl+N. (Note that there are more convenient direct menu options for all of these—apart from creating a new test case from a template.)

The New dialog

Once the wizard is visible click the type of the thing you want to create, then click the Next button.

If you click “Squish Script File” the New Squish Test Script dialog (Section 16.3.8) will replace the "New" dialog. This dialog is used to add a shared test script file (e.g., a script that contains functions you want to share amongst your test cases).

If you click “Squish Test Case” the New Squish Test Case wizard (Section 16.3.6) will replace the "New" dialog. This dialog is used to create a new empty test case.

If you click “Squish Test Case from Template” the Create Test Case from Template dialog will replace the "New" dialog. This dialog is used to create a new test case based on the specified template. (Note that there are no default templates, so you will need to create at least one template to be able to use this option. A Test Case Template can be created using the Test Suites view (Section 16.2.16)'s Test Cases list's context menu.)

If you click “Squish Test Data File” the New Squish Test Data dialog (Section 16.3.7) will replace the "New" dialog. This dialog is used to import shared test data that can be used by the test suite's test cases.

If you click “Squish Test Suite” the New Squish Test Suite wizard (Section 16.3.9) will replace the "New" dialog. This dialog is used to create a new test suite.

16.3.6. New Squish Test Case wizard

This dialog is used to create a new test case within the current test suite. It can be invoked by clicking the Test Suites view (Section 16.2.16)'s New Test Case toolbar button or by clicking File|New Test Case or File|New|New Test Case, or via the New dialog (Section 16.3.5). (See also the New Test Case action (Section 16.1.1.28).)

The New Squish Test Case wizard

Once the wizard has appeared, enter the name of the new test case and click the Finish button to finish. At this point an empty test case with the given name will be created (prefixed with tst_ if it isn't already), ready for a new test script to be entered or recorded.

16.3.7. New Squish Test Data dialog

This dialog is used to add test data for a particular test case or to be shared by an entire test suite. It can be invoked by clicking File|New|Squish Test Data, or via the New dialog (Section 16.3.5).

The New Squish Test Data dialog

The Test Data Filename should be entered first. The filename should be in .tsv (tab-separated values format), .csv (comma-separated values format), or .xls (Microsoft® Excel™ spreadsheet format—but not .xlsx format). If entering the filename directly isn't convenient because you want to pick the file using a file chooser dialog, close this dialog and open the Import Squish Resource dialog (Section 16.3.3) instead.

With any resource you have two choices as to its location: it can either be stored within a particular test case or it can be stored in a place that is accessible to all the test suite's test scripts. Unless the test data really is specific to one particular test case it is almost always more convenient to store it so that it can be shared by the entire test suite. If you just want to copy the data into the current test case check the Create file in Test Case radio button. And if you want to copy the data so that it can be shared by all the test cases check the Create shared File in Test Suite radio button. Then, in either case, click the Finish button.

See also the New Squish Test Script dialog (Section 16.3.8).

16.3.8. New Squish Test Script dialog

This dialog is used to add a test script (e.g., containing supporting functions) for a particular test case or to be shared by an entire test suite. It can be invoked by clicking File|New|Squish Script File, or via the New dialog (Section 16.3.5).

The New Squish Test Script dialog

The Test Script Filename should be entered first. The filename should be for the same scripting language as that used for the test suite's test cases. If entering the filename directly isn't convenient because you want to pick the file using a file chooser dialog, close this dialog and open the Import Squish Resource dialog (Section 16.3.3) instead.

With any resource you have two choices as to its location: it can either be stored within a particular test case or it can be stored in a place that is accessible to all the test suite's test scripts. Unless the test script really is specific to one particular test case it is almost always more convenient to store it so that it can be shared by the entire test suite. If you just want to copy the test script into the current test case check the Create file in Test Case radio button. And if you want to copy the test script so that it can be shared by all the test cases check the Create shared File in Test Suite radio button. Then, in either case, click the Finish button.

See also the New Squish Test Data dialog (Section 16.3.7).

16.3.9. New Squish Test Suite wizard

This dialog is used to creat a new test suite. It is invoked by clicking the Test Suites view (Section 16.2.16)'s New Test Suite toolbar button or by clicking File|New Test Suite or File|New|New Test Suite, or via the New dialog (Section 16.3.5). (See also, the New Test Suite action (Section 16.1.1.29).)

The New Squish Suite wizard

The use of this wizard is described in the tutorials:

16.3.10. Open Perspective dialog

This dialog is used to open a particular perspective. It is invoked by the Open Perspective action (Section 16.1.1.36).

The Open Perspective dialog

By default the Squish IDE has three perspectives (see Perspectives (Section 16.1.2)) each of which can be opened directly using the appropriate action—Squish Test Management Perspective action (Section 16.1.1.70), Squish Spy Perspective action (Section 16.1.1.68), and Squish Test De­bug­ging Per­spec­tive action (Section 16.1.1.69). Note that in practice is not necesary to open any of these perspectives manually since the Squish IDE automatically opens the right one depending on context. So this dialog is only really useful if you have created your own custom perspectives and want to choose one of them. (See the Customize Perspective dialog (Section 16.3.1).)

16.3.11. Pref­er­ences dialog

This dialog is used to set the Squish IDE's global preferences. It is invoked by the Preferences action (Section 16.1.1.38).

The Preferences dialog

The screenshot above shows the dialog's first section's first pane. The dialog has a lot of sections (“Dynamic Languages”, “General”, etc.), and most of thes have several panes. For example, the Dynamic Languages section has its own pane plus “Debug” and “Validators” child panes. Some child panes have their own child panes and so on. Most of the dialog's panes are inherited from Eclipse and most of them are rarely used. Here we will only document the most important panes, and within them the most important options.

In general, all the panes have a Restore Defaults button which restore's the panes's settings to their defaults and an Apply button which applies any changes you have made. If you make a mistake and don't want to restore the defaults (because your previous non-default settings are what you want), simply click the dialog's Cancel button—but note that this will not revert your changes if you clicked the Apply button. To accept your changes click the OK button.

16.3.11.1. Dynamic Languages pane

The Dynamic Languages pane is used to set various “DLTK” (Dynamic Language ToolKit) settings.

The Preferences dialog Dynamic Languages pane

Probably the only interesting setting is the Report problems as you type checkbox. If this is checked syntax errors are highlighted as you edit (and also indicated in the line numbers margin).

The Dynamic Languages pane has two child panes, Debug and Validators. These are very rarely needed and are not documented here. (Note that the Dynamic Languages Debug pane is not concerned with debugging test scripts.)

16.3.11.2. General pane

The General pane is used to set some miscellaneous settings. This pane has many child panes (some of which have their own child panes and so on).

The Preferences dialog General pane

Probably the most interesting setting is the Open mode. Squish defaults to Double click mode which means that you have to double-click test cases to get their code to appear in a code editor and so on. Setting the mode to Single click can save a lot of needless mouse clicking.

16.3.11.2.1. General pane's child panes

The General pane has many child panes. Here will will merely mention those that have settings that are likely to be of interest.

The Appearance pane has a Colors and Fonts child pane in which it is possible to customize the colors and fonts used by the Squish IDE and in particular by the Editor view (Section 16.2.6)s. To change the fonts, expand the Colors and Fonts pane's tree view's Basic item; the last two items concern text fonts: click one of these and then click the Edit button to set the font. Usually it is best to set both fonts to be the same. The same tree view can be used to set various colors—simply click the color of interest and then click the Edit button to choose a new color. There are other top-level items in the tree such as Debug, Dynamic Languages, and so on, so you can customize fonts and colors in very fine detail if you wish. The Appearance pane also has a Label Decorations child pane, but this is not currently used by the Squish IDE.

The Content Types pane can be used to set up file type associations. For example, Squish's non-scriptified verification points (such as screenshot verifications) are recorded in an XML-format file. If you wanted to use a custom file extention for such files you could add a file association in this pane. To do this, navigate in the Content types tree to the Text item then inside that tem to the XML item and then inside that item to the Verification Point item. (It is also possible to specify a default encoding but we recommend always using UTF-8 which is the default.)

The Editors pane and its child panes can be used to set up some general and some language-specific editing preferences. The Editors pane itself can be used to set the number of recently opened files that are available from the File menu, and to restore (or not) editor state when the Squish IDE is started up. The File Associations child pane can be used to associate file types with particular editors. For example, to make the Squish IDE open .pyw files using its Python editor, click the File types Add button (the top-most Add button) and enter a file type of *.pyw. Then click the new *.pyw File types entry if it isn't already selected and click the Associated editors Add button and choose the Python Source Editor.

The Editors pane's Text Editors child pane itself has a number of options, plus its own child panes. Use the Text Editors pane to customize general editing features such as the undo history size, the displayed tab width, whether to show line numbers, and so on. It is also possible to customize a limited range of colors here too. The child panes provide means of customizing the cursor (in the Accessibility pane) and the code annotations (in the Annotations pane). There are also some other rarely used child panes.

The Editors pane has one other direct child pane, Keys. This can be used to change the Squish IDE's keyboard shortcuts. Of course, if the shortcuts are changed this will invalidate some or all of those shown in this manual's Keyboard Shortcuts (Section 16.4) section.

The Perspectives pane is used to control some of the high level behavior of perspectives, such as whether a newly opened perspective replaces the current perspective (the default) or appears in a new window.

The Search pane is used to control some general features that apply to the Search view (Section 16.2.13).

The Workspace pane and its child panes control some aspects of the Squish IDE's behavior such as the automatic save interval and the default text encoding. Squish always and only uses the UTF-8 encoding so this setting should never be changed. Of the Workspace pane's child panes, the Build Order pane isn't used by Squish, and the Linked Resources pane's Enable linked resources checkbox must be checked—or the Squish IDE simply won't work properly. The Local History pane can be used to control a certain amount of undo history—even between sessions.

16.3.11.3. JavaScript pane

The JavaScript pane and its child panes are used to set various JavaScript-specific options.

The main pane is empty and neither the Console nor the Debug panes (or the Debug pane's child panes) are used by Squish. The other panes are used however. The Editor pane is used to control how the caret is positioned during navigation and whether to use spaces or tabs and the what and how much indentation to use. This pane also has some child panes. These are used to control such things as folding and syntax highlighting, code templates, and whether the editor closes strings and opening brackets of various kinds. The Error/Warnings child pane is used to control how strict the editor is about JavaScript syntax. The Formatter child pane is used to control how JavaScript is formatted by the editor. The Interpreters pane is used to specify which JavaScript interpreter to use. Squish uses its own built-in JavaScript interpreter but this option could be used to influence how the JavaScript editor does its syntax highlighting and error reporting. The Task Tags child pane is used to manage a list of special words that the Squish IDE must recognize and highlight inside JavaScript comments—for example, FIXME or TODO.

16.3.11.4. Perl EPIC pane

The Perl EPIC pane and its child panes are used to set various Perl-specific options.

The Perl executable setting is from Eclipse—it has no effect on test script execution. The Perl EPIC pane has a number of child panes including an Editor pane that itself has child panes (which are not documented here). The Editor pane can be used to set what and how much to indent, syntax highlighting colors, and whether the editor closes open quotes and various kinds of brackets. Those who use the Squish IDE to create Perl modules or who are deeply into Perl programming may wish to enable the Squish IDE's Module::Starter and Perl::Critic functionality—but these features are too specialized to be documented here. The Source Formatter pane is used to control how the editor formats Perl source code. The Task Tags child pane is used to manage a list of special words that the Squish IDE must recognize and highlight inside Perl comments—for example, FIXME or TODO.

16.3.11.5. Python pane

The Python pane and its child panes are used to set various Python-specific options.

The Python pane has no options of its own but it does have various child panes. The Debug child pane is not used by the Squish IDE. The Editor pane is used to control how the caret is positioned during navigation and whether to use spaces or tabs and the what and how much indentation to use. This pane also has some child panes. These are used to control such things as folding and syntax highlighting, code templates, and whether the editor closes strings and opening brackets of various kinds. The Interpreters pane is not used by the Squish IDESquish uses the Python interpreter it is shipped with. The Task Tags child pane is used to manage a list of special words that the Squish IDE must recognize and highlight inside Python comments—for example, FIXME or TODO.

16.3.11.6. Run/Debug pane

The Run/Debug pane and its child panes are used to set some general options concerning the running and debugging of test scripts.

The Run/Debug pane itself can be used to set some basic behaviors, for example what to do when a breakpoint is hit, and various color settings. It is best to at least keep the Activate the ... checkboxes checked. The Console child pane is not used by the Squish IDE. The Launching child pane can be used to control the Squish IDE's behavior when running a test, although options relating to “building” are ignored. It is best to have the Save required dirty editors before launching set to Always (the default), or at least to Prompt; setting it to Never introduces a risk that test edits could be lost in the unlikely event that the Squish IDE crashes. The Launch pane's Default Launchers sub-pane is ignored by the Squish IDE. The Launch pane's Launch Configurations pane should not be used. The Run/Debug pane's Perspectives child pane is ignored by the Squish IDESquish will always use the Squish Test Debugging Perspective (Section 16.1.2.3) when debugging is required. The String Substitution child pane is rarely needed and not documented here. The View Management child pane is used to control some aspects of how perpectives behave regarding their views.

16.3.11.7. Squish pane

The Squish pane and its child panes are used to control various Squish-specific settings.

The Preferences dialog Squish pane

The Squish pane itself shows the Squish tools folder being used by the Squish IDE. This folder can easily be changed by navigating to another folder in the tree. This is useful when you have AUTs that use different GUI toolkits and want to switch between toolkits while using the Squish IDE.

16.3.11.7.1. Squish pane's child panes

The Squish pane has several child panes: Application Behavior, Browser, Logging, Playback, Recording, Remote Testing, and Test Creation, all of which we will briefly describe here.

The Application Behavior pane is used to set how long Squish should wait for an AUT to start up before giving up and how long Squish should wait for any given response from the AUT. (The response time can also be set using the squishrunner's or squishserver's setResponseTimeout option (see Configuring squishrunner (Section 15.4.1.7) or Configuring squishserver (Section 15.4.2.3)). (From Squish 4.2, the Application Behavior pane is in the Squish Server Settings dialog (Section 16.3.15), not the Preferences dialog.)

The Browser pane is only relevant to those testing web applications since it is used to set the browser to use for web testing. (From Squish 4.2, the Browser pane is in the Squish Server Settings dialog (Section 16.3.15), not the Preferences dialog.)

The Logging pane provides some settings to achieve finer control over logging. (Note that the IDE Internal Logging Level affects only the Squish IDE's internal log. Occassionally froglogic's support staff may ask you to set its level to Verbose when trying to help solve a problem that you have encountered.)

The Playback pane is primarily used to set the snooze factor. This is only relevant to calls to the snooze function—and this function has been almost completely replaced by calls to Squish's wait functions such as the waitForObject function. (From Squish 4.2, the Playback pane's mouse cursor animation setting is in the Squish Server Settings dialog (Section 16.3.15)'s Playback pane, not the Preferences dialog.)

The Recording pane is used to control how Squish records tests. The default settings are to synchronize based on object existence (i.e., using Squish's wait functions such as the waitForObject function), and to compress events (i.e., to record a mouse move from one position to another as a single mouse move rather than as lots of smaller moves). These defaults are highly recommended since they produce the most robust and shortest test scripts possible. If you choose to use time based synchronization, Squish will record calls to the snooze function rather than to the wait functions; but be aware that this is almost always less reliable than using wait functions. (And if you hit a real problem using a wait function you can always set the timeout for the wait function's call manually to a longer duration; or insert a snooze manually if necessary.) Switching off event compression won't affect recording and playback reliability, but could lead to recorded test scripts having many more lines than with event compression on.

The Remote Testing pane is used to control which computer tests should be executed on. The default settings tell the Squish IDE to start a local squishserver whenever necessary (i.e., to record or play back a test), on Squish's default port. If you want to run the squishserver on a remote machine you can enter the remote machine's hostname and the port to use. See Distributed Tests (Section 15.1.2) for more about this topic.

The Test Creation pane is used to specify the Test Case Template directory and the default scripting language to use for new test suites (which can be overridden when a new test suite is created of course). A Test Case Template can be created using the Test Suites view (Section 16.2.16)'s Test Cases list's context menu; see also Testcase Templates (Section 15.12).

16.3.11.8. Tcl pane

The Tcl pane's child panes are used to set various Tcl-specific options.

The main pane is empty and none of the Console, Core, Debug, Interpreters, Libraries, or Man pages panes (or any of their child panes) are used by Squish. Many of the other panes are used however. The Code Templates pane can be used to create Tcl template files (separately from Squish's own file template mechanism). Some very basic predefined templates are provided and these can easily be edited or custom ones added. The Editor pane is used to control how the caret is positioned during navigation and whether to use spaces or tabs and the what and how much indentation to use. This pane also has some child panes. These are used to control such things as folding and syntax highlighting, code templates, and whether the editor closes strings and opening brackets of various kinds. The Task Tags child pane is used to manage a list of special words that the Squish IDE must recognize and highlight inside Tcl comments—for example, FIXME or TODO.

16.3.11.9. Team pane

Neither the Team pane nor any of its child panes has any effect in the Squish IDE, so none of these panes are documented here.

16.3.12. Screenshot Verification Point dialog

This dialog is used to compare expected and actual screenshots and to configure how screenshot comparisons work on a per-screenshot basis. It is invoked by right-clicking a failed screenshot verification in the Test Results view (Section 16.2.15) to pop up the context menu and then choosing the context menu's View Screenshot Differences menu item. (See also, Setting Masks and Modes (Section 16.3.12.1) for another way to invoke the dialog.)

The Screenshot Verification Point dialog

The dialog has some controls that apply generally: these are shown along the bottom and consist of zoom in and zoom out buttons, a restore to original size button, a button to show or hide the mask, a button to show or hide highlighting (i.e., show or hide a red outline around differences), and a button to pop up a color chooser dialog to choose the highlighting line color. Then there is a Save button to save the settings for the current screenshot, and a Cancel button for closing the dialog without saving any changes.

The dialog's first tab (Differences) shows the difference between the expected and actual image. This tab offers four different ways to view the difference with the default being Flicker view where the expected and actual images are shown alternately (and with differences outlined in red). The flicker speed can be set using the control on the right.

The Differences tab's Subtract view shows the differences by removing all the common pixels and just leaving those that differ between the two images. The way the subtraction works can be influenced by changing the HSV (Hue, Saturation, Value) color settings, and by checking or unchecking the Invert checkbox.

The Differences tab's Gray Diff view shows the differences by removing all the common pixels and just leaving those that differ between the two images. The way the differencing works can be influenced by changing the Contrast setting, and by checking or unchecking the Invert checkbox.

The Differences tab's Split View view shows the left half of the expected image and the right half of the actual image with a vertical slider inbetween which can be used to vary the proportions to show more of one and less of the other.

The dialog's second tab (Mask) shows the expected and actual images. It also provides tools (in the form of buttons at the right hand side of the dialog) for adding positive and negative masks, for masking a highlighted region, and for removing masks. (Most of these buttons are only enabled if the global Show/Hide Mask toggle button is pressed down, i.e., is set to show the mask—the highlighted region button is only enabled if the global Show/Hide Highlighting button is pressed down.)

The dialog's third tab (Comparison Mode) is used to set the comparison mode. By default Strict mode is used which does a straight pixel-by-pixel comparison and where any difference is counted as a failure (i.e., as the actual and expected images being different). If Strict mode is too strict there are two other modes that can be used. Pixel mode can be used to set a threshold—this is, in effect, a tolerence of up to a specified percentage of pixels being different. Histogram mode is similar to Pixel mode, only using a different comparison algorithm and with two controls for influencing the algorithm's behavior: Bins (how many pieces to divide the image into), and Threshold (how much difference is tolerated for each piece before a difference is flagged).

16.3.12.1. Setting Masks and Modes

It is possible to set the Mask and Comparison Mode for a screenshot verification point before running a test (or between test runs), or when there is no failed screenshot test in the Test Results view (Section 16.2.15) (so no View Screenshot Differences context menu item). This is done by clicking the VPs tab in the Test Suites view (Section 16.2.16)'s Test Case Resources list and then clicking (or double-clicking depending on your settings) the image verification point whose Mask or Comparison Mode you want to modify. This will result in the Verification Point being shown, along with a tiny Edit Verification Point button. Click this button to invoke the Screenshot Verification Point dialog. The dialog will pop up with only two tabs, Mask and Comparison Mode—the Differences tab does not appear because the only image available is the expected image. The Mask and Comparison Mode tabs can be interacted with as described above, and if you save the settings they will be used next time the test that uses the verification point is run.

16.3.13. Search dialog

This dialog is used to perform sophisticated searches across files. It is invoked by using the Search action (Section 16.1.1.60). (If you just want to do a simple find or find and replace in an Editor view (Section 16.2.6) use the Find and Replace action (Section 16.1.1.16) instead.)

The Search dialog

This dialog has several tabs but we will only very briefly describe the File Search tab (which is the one shown by default). The first combobox is used to specify the text to search for. The combobox keeps a record of texts used this session so it is easy to drop down and pick a previous search text. By default the search uses very simple glob-style wildcards, but you can use full regular expressions and control case sensitivity using the appropriate checkboxes if you wish. The File name patterns combobox can be used to restrict the names of the files that are searched in. For example, if your scripting language is Python, you could set the pattern to be “*.py” so that only Python files are searched. The dialog has some other more advanced settings, and can even be used to replace the matching text across files, but these features are not covered here. After performing a search a Search view (Section 16.2.13) appears in the current perspective showing a tree view of the files searched and the line numbers within them where the search text matched.

The other tabs are all scripting-language-specific. They allow you to search for text in all the files containing source code in the tab's scripting language (e.g., all the JavaScript files or all Python files), and where the search text matches the name of a type (class), method (or function), or field (attribute).

16.3.14. Show View dialog

This dialog is used to open a view that isn't already open. It can be invoked using the Show View action (Section 16.1.1.63). (See also, the Show View Menu action (Section 16.1.1.64).)

The Show View dialog

The Squish IDE provides so many views that the dialog shows them in a tree view grouped by category. Views that are already visible are shown grayed out. One view that isn't shown by default but which can be useful when you need technical support is in the Squish Tests group—the Runner/Server Log view. The Squish IDE remembers which views are showing in which perspectives between sessions, so you only have to add a view once for it to always be shown. Correspondingly, you only have to click a view's close button to get rid of it.

16.3.15. Squish Server Settings dialog

This dialog is used to control various aspects of the squishserver that the Squish IDE uses when recording and playing back tests.

The Squish Server Settings dialog

This dialog is used to set Squish's timeouts for AUT startup time and response time, to specify the web browser to use with Squish for Web, and whether to animate the mouse cursor on playback. The dialog also contains a Manage AUTs panel that replaces the Manage AUTs dialog (Section 16.3.4) used in Squish 4.0 and 4.1.

The Manage AUTs panel is used to manage the Mapped AUTs, AUT Paths, and Attachable AUTs that are registered with the squishserver. (See AUT Paths and Mapped AUTs (Section 15.3.2).)

Any child item shown in this dialog can be removed by clicking the Remove button. To add a new Mapped AUT, AUT Path, or Attachable AUT, first click the appropriate parent item (e.g., “Mapped AUTs” if you want to add a Mapped AUT), and then click the Add button. Once you have finished with the dialog click the Close button.

It is also possible to register and unregister AUTs using Squish's command line tools; see AUT Paths and Mapped AUTs (Section 15.3.2).

(Added with Squish 4.2.)

16.3.16. Switch to Editor dialog

This dialog is used to make one of the editor views' tabs the active one (i.e., the one shown and with the keyboard focus). It can be invoked using the Switch to Editor action (Section 16.1.1.75).

The Switch to Editor dialog

One convenience of using this dialog is that it shows the path as well as the filename of the files being edited. This is particularly useful for Squish 4.0.x since it only shows the filenames on the Editor view (Section 16.2.6) tabs (e.g., test.py, test.py, test.py). (Note that if you hover the mouse over an Editor view (Section 16.2.6) tab the full path is shown.)

To switch to an particular tab simply click the name of the file in the list and then click the Close button. There are also buttons for selecting multiple tabs and for closing and saving.