Recent Changes to HTML TADS

Note that we've tried to keep all of the documentation that accompanies this release up-to-date with these changes. This file is provided as a quick overview for experienced TADS users so that you can quickly see what has changed since the last version you installed.

Changes in Release HT-19 (TADS 2.5.10/3.0.16)

• The Windows version has been updated to the latest support libraries for the PNG and MNG formats; specifically, libpng 1.2.22, zlib 1.2.3, and mnglib 1.0.10.
• TADS 3 Workbench for Windows didn't properly restore the "treat warnings as errors" project setting when loading a project (in other words, Workbench always forced this option to the default "on" setting every time a project was loaded). This has been fixed.
• In Workbench on Windows, double-clicking on an error message in the Debug Log window when said window was maximized left all of the window's text up to the cursor click selected. Only the error message line itself should have been left selected; this is fixed now.
• A bug in the TADS 3 editor mode caused incorrect auto-indenting if there was trailing whitespace after the function's open brace. This has been corrected.
• In Workbench for Windows, the "Build Source ZIP" command sometimes omitted extension files that were directly in the "Extensions" folder set in the options - that is, files that were stored directly in this directory, rather than in a sub-folder. This happened when the only extension files in a project were in the main Extensions folder (i.e., the project didn't include any extension files that were in sub-folders of that main folder). This is now fixed.
• The HTML renderer sometimes incorrectly calculated the width of tables and banners that contained hyperlinks. The renderer incorrectly treated a hyperlink as implying a possible link-break point for the purposes of the width calculation, even though hyperlinking doesn't by itself have this effect on layout. This didn't affect the way hyperlinks were actually laid out, but rather affected the size calculation for containers such as tables and banners. The visual effect was that banners and tables containing hyperlinked text that didn't were sometimes to narrow for their contents. This has been corrected.

Changes in Release HT-18 (TADS 2.5.10/3.0.15.3)

• HTML TADS for Windows sometimes "froze" when running on systems localized for East Asian languages. The problem was sporadic - it sometimes happened and sometimes didn't, essentially at random; but when it happened, the triggering conditions were (a) that the Windows default code page for non-Unicode applications was for a multi-byte character set (such as code pages 932, 936, 949, or 950), and (b) certain HTML entity (&xxx;) markups where displayed, such as the typographical quote marks (‘, ’, “, ”). The bug was a bookkeeping error in the HTML parser in the handling of multi-byte characters; it has been corrected.
• In the past, if the HTML source text for a table was of just the right length, it was possible for the text following the table to be rendered twice when first displayed. (This only happened during the initial layout - manually forcing a display refresh, such as by resizing the game window slightly, corrected the displayed text.) The problem was triggered by a particular arrangement of the HTML source text in the system's internal output buffers, so the output had to be of just the right length and had to occur at just the right point in the output sequence. The chances of encountering the bug in practice were therefore fairly remote. The bug has been fixed.
• HTML TADS for Windows didn't correctly play back digital audio files (WAV, OGG) encoded with odd (non-even) sampling rates (e.g., 11025 samples per second). Depending on the playback duration, such files would play back partially correctly, then switch to bursts of white noise. This has been corrected.
• Under certain rare conditions, Workbench on Windows failed to properly restore the docked-window configuration when loading a new project while another project was already loaded. The symptom was that one or more docked windows would show up along the wrong edge of the window - for example, a window that was docked along the left edge of the screen when the project was last used might be docked along the bottom edge instead when the project was re-opened. The exact conditions that triggered the problem were essentially random, so even if you encountered this bug, it probably only happened some of the time. The problem is now fixed.

Changes in Release HT-17 (TADS 2.5.10/3.0.15.2)

• The Workbench debugger on Windows now tries to be smarter about selecting the expression text for "tooltip" evaluation. (Tooltip evaluation happens when you let the mouse pointer hover over an expression in the source code for a few moments: the debugger evaluates the text under the mouse as an expression, and shows the result in a little pop-up window.) In the past, the debugger simply used the single word under the mouse as the expression text. The debugger now looks beyond the single word, as follows:
  • First, if the mouse is over a parenthesis ("()") or square bracket ("[]"), the debugger looks for the matching delimiter, and uses the entire stretch between (and including) the delimiters. Otherwise, the debugger uses the single word under the mouse.
  • Next, if the result so far starts with a "[", and the preceding character isn't an operator of some kind, the debugger adds the part before the "[", applying the first rule above to find its limits. Otherwise, if the character preceding the result so far is a ".", the debugger adds the part before the ".", using the first rule above to find its limits.
  • The debugger repeats the second rule above as long as it finds more "prefix" expressions to add.

  The new rules are convenient for index expressions ("lst[i]") and object property expressions ("obj.prop"). If you point to either of the brackets in an index expression, the debugger evaluates the entire list-and-index expression; you can still get just the index part by pointing to the part within the brackets, and just the list part by pointing to the part before the brackets. Similarly, if you point to the property name in an "obj.prop" expression, you get the whole "obj.prop" expression result; if you want just the object part, point to it.

  Note that if you select a range of text with the mouse and point to the selected range, the debugger evaluates the entire selection, just as in the past. This lets you override the default "smart" behavior to evaluate the exact expression you want, for times when the default selection rules don't give you the results you're looking for.

• The Workbench debugger on Windows incorrectly showed "tooltip" expressions while the program was actively running. These expressions should only pop up when the program is stopped in the debugger; when the program is running, there's not a meaningful context in which to evaluate anything. This has been corrected.
• TADS 3 Workbench for Windows didn't properly restore the "no verbose errors" project setting when loading a project (in other words, Workbench always forced this option to the default "verbose errors" setting every time a project was loaded). This has been fixed.
• Workbench for Windows rearranged docked windows incorrectly when a running game was terminated while the main Workbench window was minimized. Docked windows were shrunk down to zero size on restoring the main window in this case. This has been corrected.
• HTML TADS on Windows now uses the native Windows half-tone drawing mode for scaling images. This is a slightly slower drawing mode, but yields much better results when an image is drawn at an on-screen pixel size different from its native dimensions.
• The TADS 3 editor mode in Workbench for Windows incorrectly colored "this" as a keyword; it no longer does this. (This came about because the TADS 3 coloring module is based on Scintilla's C++ coloring module: "this" is a keyword in C++, so this simply reflects some inherited code that needed further customization.)
• The New Project Wizard in TADS 3 Workbench for Windows erroneously copied some information from a currently open project to the new project being created: bookmarks, special files, Web extra files, "feelie" files, and Notes & Miscellaneous files. This has been corrected.
• On some Windows systems, the Workbench documentation search feature was unable to build its search index due to a permissions violation creating a temporary file. The indexer tried to create a temporary file in the root directory of the C: drive, but on some Windows systems this location is protected against writing by normal users. The indexer now uses a different temp file location that should be more reliable.
• On some systems, the Windows Workbench documentation searcher sometimes failed to build the search index on the first search attempt due to a filename error. This has been corrected.
• Starting in build Win107, Workbench for Windows automatically creates the object and symbol file output directories as needed when running the compiler to build the project. However, it didn't also create the output directory for the .t3 file itself. Workbench now also creates the .t3 output directory if it doesn't already exist.
• The TADS syntax coloring mode in Workbench on Windows didn't correctly color text within a double-quoted string that contained an embedded << >> expression within an HTML tag. The syntax colorer treated the part after the first > at the end of the embedded expression as though it were the closing > of the enclosing HTML tag, whereas it should have treated that > as part of the >> sequence delimiting the embedded expression. The coloring from that point forward within the string was wrong, because the colorer's internal state was out of sync with the contents of the string. This has been corrected.
• In the TADS 3 Library Reference Manual, hyperlink references to the class ExitLister incorrectly pointed to the object exitLister. This was due to (a) the LRM generator's use of the symbol name as the file name for a given object's reference page, and (b) the Window's file system's insensitivity to case. (The Windows file systems are generally case-preserving [they remember the case specified when a file is created, and faithfully reproduce it in the file index] but case-insensitive [two names that differ only in case are considered to refer to the same object]). The LRM generator now tweaks the filenames for object pages when necessary to ensure that each object has a distinct filename on case-insensitive file systems.

Changes in Release HT-16 (TADS 2.5.10/3.0.15.1)

• TADS 3 Workbench for Windows has a new option for the Project Search function that lets you search for text that spans multiple lines. To use this new option, open the File Search dialog and tick the checkbox "Collapse spaces and newlines." When this option is selected, the project searcher effectively "collapses" all of the whitespace in each file before searching it - that is, the searcher converts each series of consecutive spaces, tabs, and newline characters into a single space. The searcher then searches the file for your string or regular expression pattern. Since newlines are treated as though they were ordinary spaces, the string or pattern you're looking for will be matched even when it's split across multiple source lines. This is especially handy when searching for text within long strings in the source code, since long strings tend to be split up over several lines for readability.
• TADS 3 Workbench for Windows has a new option setting that lets you specify the main folder where you keep your extension libraries. This option is in the main Options dialog, on the new System/Extensions page. You aren't required to keep your extensions here, but there are two benefits of doing so:
  • Workbench automatically includes this folder in the library path list. Workbench and the compiler will look for files here when they're not found within your project directory.
  • The Source ZIP packager treats this directory specially. When a project file is found directly in this directory (not in a subdirectory), the Source ZIP packager will include only the stand-alone file in the ZIP file. Normally, the packager includes the entire directory (including subdirectories) of each file in your project tree, on the assumption that any files actually included in the project are probably accompanied by one or more ancillary files, such as README files or documentation. When a file is found directly in the Extensions folder, though, Workbench takes it to be a simple, stand-alone extension file.
• As described above, the Source ZIP packager now treats the Extensions directory specially when building your source ZIP file. When a file is found directly in the Extensions folder (rather than in a sub-folder), the Source ZIP packager assumes that the file is a stand-alone extension, without any accompanying files. The logic is that a more elaborate extension that includes documentation or other related files would warrant its own separate subfolder, so anything that's directly in the Extensions folder must not have any separate files associated with it. Any file that's in a separate subdirectory of the Extensions folder, or that's entirely outside of the Extensions folder, is considered to be part of a complex extension that includes ancillary files; in this case, the ZIP packager bundles up the entire contents of the directory containing the file.
• TADS 3 Workbench for Windows now automatically creates the output directories for object (.t3o) and symbol (.t3s) files if they don't already exist. Workbench creates the directories as needed just before running the compiler during each build. This eliminates the need to create these directories manually when moving a project to a new machine.
• The new <BODY> attribute INPUT lets you specify the text color for command-line input. This new attribute is parallel to the existing TEXT, BGCOLOR, LINK, VLINK, ALINK, and HLINK attributes: it takes as its value as an HTML color name or a #xxxxxx RGB value, and sets the text color for command input text throughout the document. For example, <BODY INPUT=GREEN> sets the color for input text to green. ("Input text" is text within <FONT FACE="TADS-Input"> tags.) The <BODY INPUT> attribute is useful because it lets you set a suitable contrasting text color for input text globally when you change the main window's background color with <BODY BGCOLOR=xxx>. In the past, it wasn't possible to change the input color globally - you had to use <FONT COLOR=xxx> tags on each input line instead - which sometimes left older parts of the transcript illegible after a background color change.
• In Workbench, the editor language mode for TADS 3 incorrectly classified periods as parts of identifiers when they occurred after a series of alphanumeric characters with no intervening spaces. This caused incorrect syntax highlighting in some cases. This is now fixed.
• The Workbench editor language mode for TADS 3 now recognizes VerbRule as a kind of object definition. In the past, VerbRule definitions didn't auto-indent properly because the editor mode thought they looked like function definitions.
• In the TADS 3 language mode in the editor, the Alt+Q command (Edit.FillParagraph) could get stuck in an infinite loop if it was used to reformat a string with a block of text containing no spaces that was too long to fit within the margins. This has been corrected; when an unbreakable block of text within a string is too long to fit between the margins, the word wrapper now simply lets the block overflow the right margin, then breaks the line just after the block.
• In Workbench for Windows HT-15, the auto-script QUIT-trimming feature (which optionally removes QUIT commands and/or other game-terminating event sequences from the end of an automatically captured session script) didn't function. It should now work as advertised.
• Workbench for Windows now stores its documentation search index file in the system All Users\Application Data folder, under a TADS 2 Workbench or TADS 3 Workbench subfolder. This should ensure that Workbench is able to create the index file as needed, even on machines where the user doesn't have write permission to the Program Files installation directory. (In the past, Workbench stored the index file in the program directory; on shared computers, this sometimes didn't work due to user permissions settings.)
• In Workbench for Windows HT-15, the Compile-and-Run command got stuck in an infinite loop of repeatedly recompiling the project. This has been corrected.
• Workbench on Windows crashed if it was terminated (either via the File/Exit command or by closing the main Workbench window) while the project was still running in the debugger. This is now fixed.
• In the past, when you created a new project in Workbench, the auto-script counter from any previously loaded project was propagated into the new project, so the new project's auto-scripts were numbered from whatever the last counter in the old project was rather than from 1. Workbench now resets the counter when a new project is created.
• Starting with Workbench HT-15, the position of Find and Restore dialogs was saved with the project and restored each time the dialogs were subsequently displayed. Workbench now ensures that the restored position is within the actual physical display area. In cases where the project is saved on a machine with a large monitor and then moved to another machine with a smaller monitor, this check prevents the dialog from being hidden by appearing outside of the visible display area.
• In the past, the flashing text caret sometimes failed to appear when bringing the interpreter window to the foreground after another application had been in the foreground. This happened under different circumstances, such as when asynchronous output (such as from a real-time fuse or daemon) occurred while the interpreter was in the background. This has been fixed.
• On Windows, the interpreter sometimes left a few stray pixels on the screen during command-line editing when ClearType (Windows's font anti-aliasing system) was enabled. This has been fixed.
• The TADS 3 editor mode in Workbench for Windows didn't formerly recognize the "function" keyword for function definitions when figuring the syntax indenting. This has been corrected.
• In Workbench for Windows, using the Edit/Find command sometimes incorrectly reported "No more matches" when searching backwards in a file and more matching text was present. The editor should now properly find matching text in reverse searches.
• In Workbench for Windows, the Edit/Find Again command incorrectly reported "No more matches" if the search was started with the cursor at the very start of the file. This has been corrected.
• In Workbench for Windows, the Edit/Find Again command incorrectly failed to wrap the search back to the start of the file, even when the previous search had the wrapping option enabled. The wrapping option is now respected.
• In Workbench for Windows, the Edit/Find dialog has a new scoping option that lets you search the project files, excluding libraries and extensions. The dialog now offers three scopes: Current File, which searches only within the file displayed in the active window; Project - No Libraries, which searches only within files that are part of the project tree and stored within the project directory; and Entire Project, which searches all files in the project tree, whether they're in the project directory or in separate library or extension directories.
• The Edit/Find Again command in Workbench for Windows now respects the search-scope option from the last search conducted through the Edit/Find dialog. That is, Find Again will search through the current file, the local project files, or the entire project, according to the option settings in the last Find dialog.
• When using the tabbed document UI in Workbench for Windows (that is, with the MDI child windows maximized), switching back and forth between the Help window and other document windows sometimes caused the Help window's contents to scroll slightly. This should no longer occur.
• In Workbench for Windows, docked tool windows were sometimes rearranged as the debugger opened and closed windows to match preference settings when switching between design and debug modes. For example, suppose that in design mode, you had the Project window and the Scripts window docked along the left edge of the main Workbench application window, with the Projects window on top; and suppose that you set the preferences so that the Scripts window was hidden when switching to debug mode and was shown again when switching back to design mode. In this case, on returning to design mode, Workbench sometimes rearranged the windows so that the Scripts window re-appeared above the Projects window. Workbench should now restore the original window order in these situations.

Changes in Release HT-15 (TADS 2.5.10/3.0.15)

• TADS 3 Workbench's "Build Source ZIP Package" feature now includes external libraries in the ZIP file it builds. Each external library folder is bundled into a ZIP file of its own, and then these ZIPs are included in the overall source ZIP package. This ensures that recipients of the source package have everything they need to build the project on another machine, without having to find and download third-party libraries (or, more problematically, unpublished custom libraries created by the project's author).
• TADS 3 Workbench for Windows now accepts folders in the "Notes & Miscellaneous" section of the project list. The main purpose of the Notes & Misc section is to specify additional files to be included in the Source ZIP package; the ability to add folders here is convenient if you want to include a whole batch of notes, since you no longer have to add them individually to the list. Folders in this section work just like they do in the Resource Files section: Workbench remembers the folder in the project list, not its contents, and retrieves the current contents of the folder each time you build a Source ZIP package. This ensures that you always get the current contents at the time of a build, so you don't have to worry about keeping the project list up to date as you add and remove files in the folder.
• In TADS 3 Workbench for Windows, the auto-scripting system can now optionally trim QUIT commands from the end of a script file. You can configure the particular QUIT commands to trim using the Scripts page of the Project Settings dialog. Enter one or more lists of events to trim; each list is a set of one or more regular expressions, one event per line. You can enter multiple alternative lists by separating lists with blank lines. Each time you run the game, Workbench scans the resulting auto-script file for each of the QUIT sequences listed in the project settings; if it finds a match at the very end of the new auto-script file, Workbench will delete the entire matching sequence from the end of the script.
• Workbench's integrated text editor in Windows build Win105 added a feature that wasn't documented in that release's change log: a new User Keywords syntax coloring feature. On the Syntax Coloring page of the Options dialog, for the TADS 3 language mode, new "syntax element" categories are now included for User Keywords 1, 2, and 3. These categories let you specify custom coloring for three sets of keywords of your choosing. You can specify the keywords for each category selecting the category in the Syntax Element list, then clicking the Keywords button. This opens a dialog that lets you type in the keywords to associate with the category. Whenever these keywords appear in TADS 3 files, the editor will color them according to the custom colors you select for their categories. For example, you could use this to set custom coloring for certain library macros (DefineAction, VerbRule, etc).
• Workbench for Windows now remembers the position of the Find and Replace dialogs, and restores the last position each time one of these dialogs is redisplayed. This means that if you move the dialog so that it's not covering any of the source windows, the new position will stick - you won't have to move the dialog again each time you bring it up again. In the past, Workbench centered the dialog each time it was displayed, so you had to manually move it out of the way again on each use.
• Workbench for Windows now keeps keyboard focus in the Find dialog after each "Find Next" operation, whether or not a match was found, and whether or not the latest result was in a different window from the previous result. In the past, focus moved to the current text editor window after an unsuccessful multi-file Find Next and each time the latest match was found in a new window; this was inconvenient when operating the dialog via the keyboard, since keyboard focus didn't reliably stay in the dialog after a Find Next.
• In the Windows Workbench, the TADS 3 language mode's code folding had a problem in some cases folding methods. This has been corrected.
• In the Workbench default key mapping on Windows, the keys for Edit.PopBookmark and Edit.JumpToNamedBookmark have been swapped from the previous release. Edit.PopBookmark is now Alt+J, and Edit.JumpToNamedBookmark is now Ctrl+J. The change makes the default key mapping the same as the Epsilon-style key mapping for Edit.PopBookmark, which was originally intended but was entered incorrectly in the mapping in the prior release.
• Workbench for Windows has a new command, Edit.JumpToPreviousBookmark, which jumps backwards to the previous bookmark. This does the same thing as Edit.JumpToNextBookmark, but goes the opposite direction through the source. This command isn't assigned to any key in the standard mappings.
• Workbench for Windows has two new commands to delete bookmarks. Edit.ClearAllBookmarks deletes all bookmarks throughout the project, while Edit.ClearFileBookmarks deletes all bookmarks in the current file. These commands aren't assigned to any keys in the standard mappings.
• In Workbench for Windows, you can now set the color for selected text in the editor and tool windows. This is done via the Fonts page of the Options dialog - simply select the new colors in the Selected Text drop-down lists. The color selections you make here apply to tool windows, but by default they don't apply to text editor windows. This is because Scintilla normally shows selected text with the syntax-sensitive font color against a gray background, which allows most syntax coloring to remain visible even in a selected region. If you want to override this feature and use custom colors, check "Override Scintilla selection color in editor windows." Sight-impaired users who use screen readers should note that some screen readers use the font color to detect selected regions, so Scintilla's non-standard selection coloring will prevent such screen readers from detecting selections. To make Scintilla use the standard Windows selection colors, set the Selected Text colors to "Automatic" and check the "Override" box.
• The integrated editor in Workbench for Windows didn't show the selected custom coloring for keywords in the "User Keywords 3" list. This has been corrected.
• The TADS 3 editor mode's syntax coloring didn't properly color continuation lines of preprocessor directives (i.e., with "\" at the end of the prior line) as preprocessor directives. It also didn't indent continuation lines properly. For both purposes, the editor incorrectly treated continuation lines as regular code. This has been corrected.
• In Workbench for Windows, some of the error message dialogs were "unowned" windows, meaning they came up with their own separate Windows taskbar entries, almost as though they were separate applications. This could be slightly annoying in that clicking on the main Workbench window when one of these message dialogs was displayed brought the Workbench window to the front, but that window wouldn't accept any input until the error dialog was dismissed. To dismiss the error dialog, you had to manually navigate back to its window, which might be hidden behind the main Workbench window by now. These dialogs are now all "owned" by the Workbench window, meaning they'll always stay in front of the Workbench window; this should eliminate the navigation problem by ensuring that the error dialogs are never hidden behind the Workbench window.
• In the past, the HTML Interpreter didn't recognize <BASEFONT> as a tag with global effect when pruning old text to reduce memory usage. It now properly treats <BASEFONT> as a global tag, so it retains these tags when pruning. (The HTML Interpreter discards old text and HTML tags from the top of the window whenever the total amount of text in the window exceeds a user-specified memory threshold. The Interpreter discards only enough text to keep the total under the memory limit; since the usual limits are pretty large, this process is normally transparent to the user, since all of the discarded text should have scrolled off the top of the window long ago whenever this happens. When discarding old text, the HTML parser makes a point of discarding only tags which have no global effects, so that their removal doesn't affect any of the text that remains after the pruning.)
• In the past, Workbench for Windows didn't update the project list to reflect changes to a .tl file made within the integrated editor. This has been corrected - whenever you save a .tl file that's part of the project, the project window will automatically refresh its list of the library's contents.
• Due to a bug in Scintilla, the Stuttered Page Down command didn't work properly if the current page contained wrapped lines. This has been corrected.

Changes in Release HT-14 (TADS 2.5.10/3.0.14)

• Important note: if you're upgrading from a previous version of Workbench, and you want to use one of the updated standard key mappings, you'll have to manually load the new mapping file of your choice. Your previous settings are stored in the Workbench configuration file, and Workbench will respect your old settings until you explicitly load a new key file. To do that, go to the Keyboard page of the Options dialog, click the Load Key Map button, and select the *.keymap file you want to load (the standard mappings are in the Workbench program directory). Click OK in the Options dialog to save the new mappings.
• A few new editor features have been added to Workbench for Windows. These are described more fully in the editor help file.
  • The integrated editor has been updated to the latest, just-released version of Scintilla, 1.72.
  • The Alt+/ key binding has been replaced in this version. In HT-13, Alt+/ was bound to Ext.Edit.FormatComment. This key is now used for setting a bookmark instead (see below). The old binding isn't needed any longer because Alt+Q now serves as a multi-purpose, context-sensitive reindent command: press Alt+Q while the cursor is in a TADS comment to reformat the comment; press Alt+Q while the cursor is in a TADS string to reformat the string; press it in other TADS code to reindent the code line or region; press it in a non-TADS window to reformat a text paragraph.
  • The new command Edit.CommentRegion adds or removes commenting at the start of each line in the selected region. The command is bound to the Ctrl+8 key in the standard key mappings (this key was chosen because 8 is the asterisk key, and asterisks are commonly involved in commenting in many languages). The TADS language mode handles this by adding or removing "//" at the start of each line; other modes currently ignore the command. This command is handy when you want to quickly disable some code for testing purposes, and then later re-enable it.
  • The editor now provides a "bookmarking" feature, which lets you mark locations in source files for easy return later on. This new feature is described in detail in the Workbench help, in the Advanced Editor Features section.
  • The new editor command Edit.FindDefinition (on the F6 key in the standard keyboard mappings) searches the project for the definition of the symbol at the cursor location. The editor searches for a TADS 3-style object, class, or function definition, looking in all files included in the project list. If a definition is found, Workbench opens the file containing the definition and selects the matching symbol. Since the cursor is positioned at the matching symbol in the definition, you can search for another definition of the same symbol simply by pressing F6 again - this is useful for symbols that have more than one definition, such as via 'modify' or 'replace'.
  • The TADS mode adds a new command to reformat a literal string, applying word-wrapping and auto-indenting. You can invoke this by positioning the cursor within a string and pressing Alt+Q. The editor will automatically re-flow the string to fill out lines to the current right margin, wrapping lines at word boundaries. The reformatting leaves line breaks intact when they're adjacent to explicit formatting line break codes (\n, \b, <br>, <p>, <.p>), and won't break a line in the middle of a {format code} sequence.
  • The TADS mode now distinguishes statement braces ("{" and "}") from other operators for syntax coloring purposes. This lets you set a separate color for braces.
  • The editor now supports "code folding," which lets you selectively show and hide blocks of code. The folding system detects the lexical hierarchy of the TADS code - that is, it recognizes an object definition as a block of code, a method within an object as a block, and a set of statements enclosed in braces within a method as a block. Enable code folding using the Show Folding Controls command on the Edit menu. When folding is enabled, the editor shows "+" and "-" controls in the left margin; these work like buttons in the ordinary Windows tree control, to expand or collapse a block of the code. Folding is often helpful with large object or method definitions, because it lets you hide details so you can more easily see the big-picture structure of the code.
  • The editor now maintains a "mark," which is a temporary, ad hoc bookmark, similar to the Emacs mark. The mark is set automatically whenever you set a selection mode anchor (Edit.SelectionMode, etc.), jump to the start or end of the document, or start a regular or incremental search. You can jump to the mark with the new command Edit.SwapMark, and you can select the text between the cursor and the mark with the new command Edit.SelectToMark.
  • The incremental search command can now be used to extend a selection range. If a selection mode is in effect at the start of an incremental search, and the search is successful, the selection range is extended at the end of the search to include everything between the original selection anchor and the end of the matching search text.
  • A new Options page, Wrapping & Margins, lets you control how the editor handles long lines. You can set a right margin, which controls the line width for certain commands, and you can make the editor display a visual guide at that column. You can also tell the editor to automatically word-wrap text as you enter it when you type past the margin.
  • The TADS-mode comment formatter now uses the new margin setting as the line length when doing its word-wrapping.
  • A new command, Edit.FillParagraph, auto-formats a paragraph of plain text, filling out each line to the margin width and breaking lines on word boundaries to fit.
  • When an editor window is in TADS 3 language mode, the Edit.FillParagraph command doesn't do ordinary paragraph filling, but instead does context-sensitive TADS-code reformatting, depending on where the cursor is positioned. If a region is selected, the command reindents each line in the region, as though you'd used the Ext.Edit.SyntaxIndent command. Otherwise, if the cursor is in a comment, the command reformats the comment, the same as Ext.Edit.FormatComment; and if the cursor is within a string, the command reformats the string, the same as Ext.Edit.FormatString. This means that you don't really need to bind separate keys to the Ext.Edit.FormatString and Ext.Edit.FormatComment commands - you can simply use the Edit.FillParagraph command (Alt+Q) to do whichever type is right for the context.
  • Editor windows can show the line number for each line in the margin. Use the Show Line Numbers command in the Edit menu to control this.
• A new option (set via the Library Paths page of the Options dialog) lets you specify that library files are to be opened in read-only mode by default. When this option is set, the editor will open any file not located within your project folder as read-only. This lets you avoid accidentally editing a library file when you're browsing the file or stepping through it in the debugger. You can always make a library window writable by using the Edit.ChangeReadOnly command (which isn't assigned to a key in the default mapping). By default, this option is not set, meaning that all files are opened as writable by default.
• The project window now recognizes a few additional resource filename extensions as indicating text files that can be opened in the integrated text editor: .log, .cmd, .c, .cpp. (When you double-click on a resource file in the project window, Workbench tries to guess whether the file in question is a text file by looking at the filename suffix. If the suffix is one typically associated with plain text files, Workbench opens the file in the internal editor; otherwise, Workbench asks the operating system to open the file using whatever application is normally associated with that type of file.)
• A bug in Workbench for Windows sometimes occured when loading a project. The problem manifested as a Workbench crash in some cases, and in other cases as random rearrangement of some of the windows left open in the previous session. The problems were particularly likely to occur when loading a project after Workbench was already open. The bug has been fixed, so these problems should no longer occur.
• In HT-13, the Compile-And-Run command in Workbench initiated the build correctly, but didn't start the project running after the build completed. This has been corrected.
• The regular expression option for the project-wide search command (Find in Project Files) didn't work in the previous release - checking the regular expression box always yielded a regular expression syntax error. This has been corrected.

Changes in Release HT-13 (TADS 2.5.10/3.0.13)

• Workbench for Windows now has a built-in text editor. The integrated editor is Scintilla, which is a highly stable open-source text editing component designed specifically as a programmer's editor. Scintilla has the features you'd expect from a source code editor: multi-level undo, syntax coloring, regular expression searching, and much more.

  The Scintilla editor takes the place of the former read-only source code display window, so when you're stepping through code in the debugger, you're actually using a live editing window - this means you can make changes directly in the debugger window when you discover a problem or otherwise find something you want to change. (Of course, changes you make to the source code while debugging won't affect the running version of the program until you recompile.)

• Scintilla can be programmed to understand different programming languages, to provide appropriate syntax coloring. The integrated version recognizes TADS 3 code (of course), and it also includes support for HTML and XML. In fact, Scintilla has pre-defined syntax modes for numerous other languages - C, C++, Python, Perl, Java, BASIC, Fortran, and on and on - but to avoid clutter in the Workbench UI, we've only exposed the language modes that are likely to be useful within TADS projects.
• The TADS 3 editing mode not only provides syntax coloring, but also provides a sophisticated auto-indenter and comment formatter. The auto-indenter attempts to keep your code properly indented as you write it; whenever you press a "hot" key, the auto-indenter tries to fix up the current line to make it fit the standard indenting style. Hot keys include the return key, braces, square brackets, semicolons, and colons. The comment formatter automatically reformats a block comment when you type the "*/" sequence; it fills the comment's paragraphs for an 80-character line width and sets up a column of asterisks at the left edge.

  These auto-formatting features are designed to make your life easier - much easier - by saving you the trouble of manually fussing with the indenting as you write your source code. But they can take a little getting used to: some people find it disconcerting to have the code jumping around on its own so much. If you find that you don't like the auto-indenting scheme, you have several options for controlling it, moderating it, or eliminating it. The Indenting page in the Options dialog lets you set the auto-indent style to "syntax-based," "same as previous line," or "off." If you turn it off, the source text will be left exactly as you type it. If you set it to "same as previous line," the indenter will merely indent each new line to the same level as the previous line whenever you press return, and otherwise will leave everything alone. This page also lets you turn off the comment auto-formatter, if you find its behavior annoying. If you want to go beyond these pre-defined choices, there's one more option: you can go in and change the TADS 3 mode to make it behave exactly the way you want. We supply the source code for the TADS 3 mode - it's in tads3addin.cpp - so you can make whatever customizations you like and then recompile the plug-in DLL.

• You can now customize the keyboard, to define your own command keys. Use the Keyboard page of the Options dialog to customize key bindings. The keyboard mapping system is particularly useful if you want to make the new built-in text editor behave like another editor you're already familiar with.
• The language-mode features we just described are fully extensible with a plug-in system, in case you want to add support for another language you find useful within Workbench. The plug-in system uses DLLs containing COM objects - we chose that infrastructure because it lets you write these objects in virtually any programming language on Windows. We've provided a set of C++ classes that makes it relatively easy to write a plug-in in C++. If you're interested, refer to the "addins" directory for a bunch of source files that provide specifications and examples. The main file is itadsworkbench.h, which contains the specification of the plug-in interface. Also see wb_addin.h, which defines the framework classes. We've also supplied source code for the TADS 3 and HTML modes, both to serve as examples of how to build add-ins, and to make it easy to make minor tweaks to the behavior of those modes. Everything related to the add-ins is in the "addins" subdirectory of the main install directory.
• TADS 3 Workbench for Windows has a new Project Search feature. This lets you search all of the text files in your project for a given string or regular expression - it's like the Unix "grep" command. Use the Search for Text command on the Project menu to perform a search. If you check the Regular Expression box, the search string will be interpreted as a regular expression pattern, using exactly the same syntax that the TADS 3 VM uses in rexSearch() and the like.
• The Find dialog (for searching for text in a source file) now has a Regular Expression checkbox option. (A "regular expression" is a special kind of wildcard pattern, sort of like those "*.TXT" file searches you can do in Windows, but much more powerful.) Check this box to perform a regular expression search of a text editor window. As with Project Search, this uses the full TADS 3 regular expression syntax.
• The Find dialog is now "modeless," meaning that you can switch back to the editor window while the Find dialog is still displayed, to move the cursor or make changes to the text.
• A new Incremental Search command provides a more convenient way of searching for text in an editor window. Incremental search skips the dialog, so it can be run entirely via the keyboard. Unlike the regular Find dialog, incremental conducts the search continuously as you type in the search string; this saves time by letting you type in only as much of the search term as you actually need to locate the text you're looking for. Incremental searches have several options that can be selected via keystrokes within a search, including regular expression matching, whole-word matching, exact-case matching, and forward/reverse searches.
• A new Replace command lets you search for text in an editor window and replace each occurrence with a new bit of text. Like Find, Replace can optionally search for a regular expression pattern. The dialog lets you find and replace occurrences of a search term one at a time, so that you can individually inspect and approve each substitution, and also has a button to replace all remaining occurrences without further prompting. The dialog is modeless, meaning that you can switch back to the text window while the dialog is still running, if you want to make additional edits between replacements.
• In TADS 3 Workbench, the Project window has several new sections:
  • The Feelies section lets you list additional files to include in release packages. These files are automatically included in the ZIP Package and Windows SETUP Package builds.
  • The Web Page Extras section lets you add extra files to include in the Web page package. Any files you drop here are automatically added as links in the "Download" box on the generated Web page. This lets you add things like hints, maps, walk-throughs, and any other extra material you want to make available for download from your Web site, but which you don't want to include in the release package itself. For each file, you can set a title for its hyperlink on the generated page by right-clicking the file in the Project window and choosing "Set File Title..." from the menu. If you don't set a title for a file, its hyperlink will simply be a "friendly" version of the filename (any path or extension is removed, the first letter is capitalized, underscores are changed to spaces, and each embedded capital is preceded by a space: so misc\readMe.txt will be shown as "Read Me", for example).
  • The Notes and Miscellaneous section is a place to add files that you want to keep track of as part of the project's overall source materials, but which don't belong in any of the other Project window sections. You can use this section for things like your "to do" list, your working notes, and so on. The benefits of listing files here are (1) that you can easily open a file by double-clicking it in the list, and (2) that the "Build Source ZIP Package" command will automatically include these files.
  • The Special Files section is a little different from the other sections. Rather than containing a list of files of a particular type, it contains slots for a number of files with special purposes in certain of the release packages. Each slot is labeled with its special purpose, plus the currently assigned file, if any; you can assign a new file to a slot by dragging a file from the Windows desktop and dropping it on the slot, or by right-clicking the slot and selecting "Set File" from the pop-up menu.
• If you go to the "Windows SETUP" page of the Build Settings dialog in TADS 3 Workbench, and you click the "Edit" button to display the SETUP options editor, you'll find that many of the options that were formerly presented have been removed. The missing options have been replaced with slots in the Special Files section (see above). The new arrangement has the advantage of being more consistent overall: these special files are really just some additional, special-purpose source files for the project, and the new arrangement recognizes this by moving them into the Project window's list, where all of the other source files for the project are managed.
• In the Project window in TADS 3 Workbench, you can explicitly set the "Start Menu" title for any file in the Feelies list, and for certain of the files in the Special Files list. Set a file's Start Menu title by right-clicking on the file in the Project window, and selecting "Set File Title" from the menu. The title is only used in the Windows SETUP package; it's ignored for the Release ZIP package. Each Feelie item that's assigned a Start Menu title will be added to your game's Start Menu group, with the title you specify appearing in the group menu; other feelies are included in the package and will be copied to the user's hard disk at installation, but won't be listed in the Start menu.
• In TADS 2 Workbench for Windows, the Build Settings dialog has a new page, "Files - Special." This page lets you specify (1) a Cover Art image, which (if specified) is bundled into your compiled .gam file for use by game browsers (such as TADS Game Chest); and (2) a Windows icon (*.ICO) file to use for the Windows .EXE version of your game. Note that the EXE icon was specified in past versions via the "Windows SETUP" page of the Build Settings; that older setting has been removed, so you should use the new "Special" page to set the icon from now on.
• TADS 3 Workbench has a new set of Build commands that let you create release packages with a couple of menu clicks. These commands automate procedures that, in the past, had to be done manually using other tools, such as a ZIP program. The new packaging commands are:
  • Build Release ZIP Package: This creates a ZIP file containing the release version of your game, suitable for distributing to players or uploading to the Web (to the IF Archive, for example). The ZIP file contains a freshly compiled release build of your game (the .t3 file), plus all of the Special Files and Feelies listed in the Project window. The Resource Files listed in the Project window are automatically bundled into the compiled game. The resulting ZIP file is the "universal" edition of your game for distribution: UNZIP tools are available on virtually every platform, and the .t3 file bundled in will work on any computer with a TADS Interpreter. To distribute the game, you simply distribute the ZIP file to players. To play the game, a player just needs (1) your ZIP file, (2) an UNZIP tool for her operating system, and (3) a TADS 3 Interpreter for her OS. Almost everyone these days will already have an UNZIP tool installed, and many regular IF players will already have a TADS Interpreter. Set the output ZIP file via the "Release ZIP" page of the Build Settings dialog.
  • Build Windows SETUP Package: This command (which was included in previous Workbench versions as well, under the name "Build Windows Installer") builds an automatic SETUP program for the Windows edition of your game. The resulting SETUP program contains a freshly compiled copy of your game, compiled as a Windows executable (.EXE) program, plus all of the Special Files and Feelies listed in the Project window. The game .EXE file will automatically contain the Resource Files listed in the Project window. The resulting SETUP file is a completely stand-alone edition of your game - to distribute it, you just distribute the single installer .EXE file; to install, a player simply runs the installer. You don't need to distribute any other files, and players don't need to download or install anything else. Unlike the ZIP file edition, players don't need to have an UNZIP tool or a separate TADS Interpreter installed - the installer contains everything they need. As a result, this is by far the most convenient distribution format for players on Windows - but, of course, it has the disadvantage that only Windows users can use it. If you plan to distribute this edition, it's a good idea to distribute the ZIP edition as well - that way, Windows users get the ease of use of the SETUP edition, but people on other operating systems can still run the game. Set the output EXE file (and other options) via the "Windows SETUP" page of the Build Settings dialog.
  • Build Source ZIP Package: This creates a ZIP file containing everything that goes into building your game: the project (.t3m) file, the source files, header files, resource files, Special Files, and Feelies. This makes it easy to transfer your project to another computer, or to distribute the project to other people. Note that only "local" files are included - that is, files within the folder containing the .t3m file (or subfolders of that folder); anything else is assumed to be a third-party library, which you normally wouldn't want included since it's not part of your project's source. Set the output ZIP file via the "Source File ZIP" page of the Build Settings dialog.
  • Build Web Page: This creates a simple Web site for your game, suitable for uploading to a Web hosting service. The main page is created by filling in a template with the bibliographic information from your GameInfo.txt file (which is usually, in turn, generated from the versionInfo object defined in your game's source code), and includes a link to download the game (either as just the .t3 file or as the release ZIP package), and optionally to the Windows SETUP package and the Source ZIP package. The page will also include links for any additional files that you list in the Web Page Extras section of the Project window. Set the output directory and other options via the "Web Page" page of the Build Settings dialog. The web page builder uses a standard template to determine the layout of the page, but you can create your own custom template instead if you want to change the appearance or add special features; you can specify your custom template file using the "Custom Web Template" item in the Special Files section in the Project window.
  • Build All Packages: This builds a fresh copy of each of the packaging options: the release ZIP, the Windows SETUP, the source ZIP, and the Web Page. To be more precise, this actually builds all of the selected packages, the selections being made via the Build Settings dialog. Each package has a page in the Build Settings dialog, and each package page has a checkbox labeled "Include in 'Build All Packages'". If this box is checked, the package will be included in the build; otherwise it won't. By default, the box is checked for every package. If there are packages you don't plan to distribute, you can make the Build All Packages process run a little faster by un-checking the boxes for the unwanted packages.
• TADS 3 Workbench for Windows can now automatically capture all input events each time you run your game, creating a "script" that you can replay on a later run of the game. Here's how this works:
  • Each time you run the game, Workbench automatically creates a script file, with a name like "Auto 5.cmd", in the Scripts subfolder of your main project folder.
  • The Scripts tool window shows the list of script files, sorted from newest to oldest.
  • To replay an entire script, right-click on the desired script in the Scripts tool window and select "Replay" from the menu.
  • To replay a script only to a certain point, first open the script in the text editor by double-clicking on the script file in the Scripts window, then right-click on the last line of the script to execute, and select "Replay to Cursor" from the menu.
  • When you replay a script, Workbench will tentatively create a new auto script for the replay session, in case you type some new commands after the replay has completed. However, if you don't end up typing any new commands, so that the new script is in the end identical to the one being replayed, Workbench will discard the redundant new script. This avoids cluttering the Script list with multiple copies of the same script if you're repeatedly playing through a script as you test a series of changes.
  • Most people work on a game one section at a time, so the scripts that Workbench captures are typically most useful when they're fresh. As you move on to focus on new parts of the game, older scripts will probably become less useful, since they exercise portions of the game that you're not currently working on. This is why Workbench sorts the Script window from newest to oldest - we figure you'll usually want the most recent scripts to be closest at hand.
  • What's more, Workbench can help keep the Scripts window tidy by automatically discarding older scripts. By default, Workbench keeps the latest 25 "Auto N" scripts: each time a new script is created, Workbench deletes any Auto scripts beyond the most recent 25. You can change the maximum number of Auto scripts to keep, or you can turn off this auto-delete feature entirely, using the Scripts page of the Options dialog. No matter what the settings, Workbench will never include a renamed script in this cleanup process - the cleanup process will only delete scripts with the "Auto N" name pattern. So, if there's a script you want to keep permanently, simply rename it to something other then "Auto" followed by a number - you can do this by right-clicking on the file in the Script window and selecting "Rename" from the menu.
  • You can disable the auto-scripting feature and change the other scripting settings using the Scripts page of the Options dialog.
• Workbench for Windows has a number of enhanced user-interface features. Most of these should be familiar to most Windows users, since they're common in other applications:
  • Workbench now has multiple toolbars instead of a single main toolbar. The new documentation search and integrated editor features have increased the number of toolbar commands to the point where a single toolbar would have become quite large. The new arrangement creates groups of related commands, and puts each group in its own separate toolbar.
  • The real advantage of the separate toolbars is that you can now rearrange the layout of the toolbars, to suit your working style and the amount of space you have available on your monitor. You can move a toolbar by dragging on its left edge. You can also hide and show each toolbar individually - right-click on a toolbar to access a menu that lets you select which toolbars are visible. The main menu is itself a toolbar now, so you can arrange its position the same way (you can even hide it if you want).
  • When you maximize the document windows (the "MDI" windows), Workbench now displays a list of "tabs" that let you navigate among the windows. The tabs are displayed at the top of the document window area; click on a tab to bring up another window. Many people find the tabbed style of interface easier to navigate than the MDI style, since each window gets the full workspace when it's active, but the list of other windows is always close at hand. To switch to the tabbed interface, simply maximize a document window; to switch back to MDI mode, click the "restore" button at the right of the tab list.
  • Menu items now display icons that correspond to the toolbar buttons for the same commands. Many people find that this makes menus easier to navigate, by providing a visual cue to help spot the command you're looking for at a glance.
• You can now tell Workbench to show or hide the various "tool" windows when switching between Debug and Design modes. (Workbench is in "Debug" mode when the game is running, and "Design" mode when the game isn't running.) You can specify which windows to show and hide in each mode using the new "Tool Windows" page of the Options dialog. For the most part, the tool windows are useful only in one mode or the other; for example, the Stack window is useless in Design mode, since there's no active stack to display. This new feature is designed to give you more room to work by letting you optimize the set of tool windows displayed in each mode.
• Workbench for Windows now lets you perform a full-text search of the documentation. To run a search, type your search terms into the text box in the new Search toolbar, and click the button (or just press Return). Workbench will display a Search Results window showing a list of the pages found within the documentation containing the search terms.
• By default, the search engine looks for pages containing all of the keywords you type; if you want to look for documents containing one of several keywords, separate the words with OR (the upper-case letters are required); for example, operator OR expression searches for pages with either keyword. If you want to exclude pages that contain a certain word, type NOT (in upper-case) before the word: operator NOT expression returns pages that contain "operator" and which don't contain "expression." By default, the search engine looks for common variations of the words you type, such as plurals and verb tenses; to look for the exact word you type, put it in quotes: "operator" will match only "operator", not "operators" or "operated" or "operating". Similarly, if you want to look for an exact phrase, put the whole phrase in quotes: "thing class" searches for the whole phrase, not just the individual words.
• If you installed the version of the Author's Kit that includes the full documentation, the search engine will search your local copy of the documentation. This requires building a local index, which uses a few megabytes of disk space and could take a minute or so, but only needs to be done once. If you installed the smaller Author's Kit with no documentation, Workbench will run the search using the tads.org on-line search engine, which obviously requires an internet connection to perform the search. The on-line and local versions work the same way (they use the same search engine), but the local version is usually faster because it doesn't involve any network latency.
• The Search toolbar also lets you perform a quick search of the current document window, or a quick project-wide text search. Use the drop-down arrow in the Search bar to select "Search Current File" or "Search Project Files"; after you've done this, the Search bar will search the current file or the project source code rather than the documentation. This is a little quicker than going through the normal Find dialogs. Note that unlike Doc searches, Project and Current File searches are not keyword searches - these are simple literal-text searches that simply look for the exact text you type. The OR and NOT keywords and the quoting syntax used in the Doc search don't apply here. These searches use the default Find options (case-insensitive literal text, not regular expressions). You'll have to use the normal Find dialog, accessible through the Edit menu, if you want to set non-default search options: regular expression matching, whole-word matching, or exact-case matching.
• Workbench for Windows has some new commands on the Tools menu to work with IFIDs (Interactive Fiction Identifiers, as defined by the Treaty of Babel and used in the TADS GameInfo metadata system). First, the command "Generate IFID" randomly generates an IFID for you to use in your project. Second, the command "Read IFID From..." reads the IFID from an existing TADS game. Importantly, the Read IFID command generates the "implied" IFID for a game that was originally released without an IFID defined in its GameInfo data (or without any GameInfo data at all). This is useful because the Treaty of Babel specifies that you must use this implied IFID as the explicit IFID for any future version updates of a game previously released without an IFID - this ensures that the IF Archive and other tools will be able to recognize the new and old releases as different versions of the same game. The Babel didn't appear on the scene until mid-2006, so the many TADS games released before that time obviously don't have explicit IFIDs.
• The Windows SETUP builder has a new feature that lets you add your own custom items to the Start Menu group for your game. For users running your SETUP version, it will be much easier to find any "feelie" items you include if you put them on the start menu - most Windows users will never look at the "C:\Program Files\My Game" directory on their own after installing your game, so they'd probably never find your feelies otherwise. You can add an item to the Start menu by including syntax like this in the list of installation settings (the "Installer Options" field in the Windows SETUP page of the Build Settings dialog):

  startmenu="My Item Title" item1.htm
  

  This shows "My Item Title" as the title in the Start Menu group. When the user selects this item, Windows opens the file "item1.htm" using whatever program is associated with that file type on the user's machine. The installer automatically includes the given file in the install set, so you don't need to list it separately with a FILE= line.

  A note on file formats: It's pretty safe to assume that everyone has software installed for viewing plain text (.txt) and HTML (.htm) files, and most Windows machines have a Portable Document Format (aka Acrobat, or .pdf) reader as well. Other formats, such as Word (.doc) or other word processor formats, are less universal, so you're much better off with HTML or PDF if you want fancy formatting.

• The HTML formatter didn't properly align the text of the first line of an <LI> item in a numbered list (<OL>...</OL>). The text position was off by a few pixels to the left or right of the list margin. This has been corrected.
• In the past, in Workbench for Windows, the font popup list in the Formatting page of the Debugger Options dialog sometimes showed multiple copies of a font name. This happened because the popup list showed one copy of the name for each code page (localized character set) installed for the font; some of the system fonts support numerous code pages, so a font like "Courier New" might have shown up five or six times. The dialog now displays only one copy of each font name.
• In Workbench for Windows, when you change a #define symbol in the Project Settings dialog, Workbench reloads the list of files in the Project window to make sure that any affected libraries reflect the new #define values. Libraries (.tl files) can refer to #define symbols to determine which source files to include, so changing a #define can affect the list of included project files. In the past, this refresh operation had the side effect of forgetting all of the "file exclusions" for libraries. That is, if you had unchecked any of the checkboxes next to source files within a library in the Project tree, the checkboxes were all checked again after the refresh. Workbench now retains the checkbox settings. (Note that this only applies to files that are included both before and after the #define change. If you change a #define in such a way that the list of included files changes - say, because you change the LANGUAGE symbol from "en_us" to "fr_fr" - the checkbox settings for any old files that are no longer included in the project will be lost, and the checkboxes for any new files that weren't previously included in the project will be checked by default. Workbench can't guess at the correspondence between files in, say, the en_us library and the fr_fr library, so it can't carry over the exclusion settings when the libraries change.)
• In certain cases, Workbench for Windows was inconsolable about finding a missing source file. If you added a source file to your project, and the source file was in a subdirectory under one of the existing library directories (the directories listed in the "Library Paths" page of the Options dialog), Workbench remembered the source file's name with a relative path - so, for example, the source file was listed in the project tree as "MyLib\mysource.t". If you later moved this source file to another directory, Workbench asked as always for your help in locating the missing file. The problem appeared when the new directory didn't have the same final path element ("MyLib" in our example). In these cases, Workbench insisted on finding a file with the exact relative path "MyLib\mysource.t" - even if you explicitly selected the new "mysource.t" location, Workbench refused to accept it, repeatedly popping up the "Missing File" dialog until you hit Cancel. This has been corrected; Workbench now automatically drops the relative path prefix in these cases and just looks for the unadorned source file name.
• In a TADS 3 game, if you used a library (.tl) file in the game, and the library included multimedia resources, Workbench sometimes failed to find the resources when running a debugging build. This happened when the library you included was in a subdirectory of your main project directory, or a subdirectory of a directory in your global library path; in these cases, Workbench didn't properly take into account the relative path to the library's subfolder when looking for the resources. This has been corrected.
• The Windows HTML Interpreter didn't play back Ogg Vorbis sounds properly when they were embedded as resources in the .t3/.gam file. This has been corrected.

Changes in Release HT-12 (TADS 2.5.10/3.0.12)

This is the TADS 3.0 General Release version.

• Due to a bug in Workbench for Windows, the "Help/User Manuals" menu command sometimes failed to actually open the manual. The problem occurred when no other browser windows were open; if any browser windows were already open, the manual was launched properly. This has been corrected: the command should now work properly whether or not any other browser windows are open.

Changes in Release HT-11 (TADS 2.5.10/3.0.11)

Note: starting with this release, HTML TADS has its own release numbering, separate from that of the underlying TADS VMs. TADS 2, TADS 3, and HTML TADS are all essentially on their own separate release cycles, so the past practice of treating the HTML TADS version number as equivalent to the underlying VM version numbers was too confusing. From now on, HTML TADS releases will be identified by an "HT-n" version number. We're starting this new practice with HT-11, since this is the 11th public release. In addition, the Windows build will be identified with its own port-specific build number, so that any future bug-fix versions that only affect Windows can be differentiated.

• The Windows HTML interpreter failed to match a parameterized font name when the name was the last of multiple font names in a <FONT FACE="x,y,z"> list. This has been corrected.

Changes in version 2.5.10/3.0.10

• In Workbench for Windows, the debugger incorrectly allowed evaluating a new expression while the debugger didn't have control (i.e., while the game program was actively executing). This shouldn't have been allowed because the current context for evaluation changes continuously while the game is executing, and as a result attempts to evaluate expressions at such times could yield unpredictable results. In certain rare circumstances, this could have caused Workbench itself to crash. This has been fixed: expression evaluation is now correctly suspended during game execution. If the user enters a new expression (into the "watch expression" window, for example) while the game is executing, Workbench accepts the new entry, but simply leaves the value part blank until the next time the debugger gains control (by hitting a breakpoint, for example), at which point the expression is evaluated in the current context as usual.
• In Workbench for Windows, the New Project Wizard now sets verbose error messages by default. You can change this by going to the Build menu, selecting Settings, selecting the Diagnostics tab, and un-checking the "Verbose error messages" checkbox.
• In Workbench for Windows, if the option "Clear Debug Log when starting new build" is selected (on the Messages page of the Debugger Options dialog, accessible from the View menu), the debug log will not automatically scroll to the bottom as new messages appear. If a large number of messages are displayed during the build, this saves you the trouble of manually scrolling the window back to the top to see the first few error messages, which are almost always the ones to tackle first.

Changes in version 2.5.9/3.0.9

• The Windows HTML interpreter recognizes the new "Default" setting for a game's presentation profile. If a game's GameInfo record uses the "Default" setting, the Windows interpreter now uses the current default theme when playing the game. The current default theme is marked as such in the Themes menu, and the player can change the default at any time using a new command in that same menu. The player can also manually set a game to use the "Default" theme by editing the game's profile on the Game Chest page. Also, if a game doesn't have a GameInfo record at all, then the interpreter uses the current default theme for the game. In the past, the interpreter used the Multimedia theme in these cases.
• On Windows, the default display font for the "TADS-Script" pseudo-font is now Comic Sans MS (at 11 point). In the past, the default was Times New Roman; that's obviously not a script-style font, but it was chosen as the default because there aren't any script fonts that are guaranteed to be installed on all Windows systems. Comic Sans is a better default because (a) it actually is a script font, and (b) it's present on almost every Windows system, since it's installed as part of Internet Explorer. On those rare systems where Comic Sans MS isn't available, the operating system will automatically fall back on the default application font (usually Arial), so even these systems aren't any worse off with this change.
• The Windows HTML interpreter didn't retain the bold and italic attributes of the "TADS-Input" pseudo-font when another <FONT> tag (such as one changing the size or color of the text) was nested within the <FONT> tag that selected the "TADS-Input" font. This is now fixed.
• The Windows interpreter no longer shows anything in the status area at the bottom of the interpreter window when the mouse is hovering over a hyperlink with an explicitly empty title attribute (TITLE=""). In the past, the interpreter acted as though the TITLE attribute wasn't present at all, and displayed the hyperlink's HREF text. In many cases, the HREF text is just some internal code for the game's own use, and so isn't meant for the player's eyes. In the past, the only way to suppress the status area display of the HREF was to use a non-empty TITLE attribute instead, which supersedes the HREF text in the status area display. In some cases, though, it's useful to be able to show nothing at all in the status area for a link. You can now do that by using TITLE="" in the <A> tag.
• The HTML interpreter didn't properly show TITLE tags when the mouse was hovering over a hyperlinked image. This now works correctly.
• A bug in the HTML renderer resulted in an incorrect display layout when a table cell contained nothing besides a nested table, and the nested table used a background color or image. In these cases, the background of the nested table was sometimes displayed at an incorrect location on the screen. (The problem only occurred when the nested table was the only thing in its cell - if there was anything else in the cell, even a "\n" or one of the special HTML non-breaking space characters, the display was correct.) This is now fixed.
• The HTML renderer sometimes gave a nested table too much space in its enclosing table's layout, leaving unwanted empty space in the enclosing column. This problem usually only showed up when a table contained a cell that contained only a nested table. This has been fixed.
• A bug in the HTML interpreter caused unpredictable beahvior, including crashing the interpreter, when using animated images within a banner-API window. The bug usually manifested when the program deleted a banner window that was displaying an animated image at the time of the deletion. This has been corrected.
• In the past, the <NOBR> tag didn't always work properly within tables. Depending on the table's surroundings, <NOBR> sections within a table sometimes caused incorrect layout of the table's contents. This is now fixed.
• In some cases, an IMG tag with separate ASRC and/or HSRC images didn't update the display properly on a click on the image or when the mouse hovered over the image. This has been corrected.
• On Windows, the inputDialog() function used a fixed size for the buttons it displayed, so a long name could overflow the space allowed for the button. This made the dialog confusing, since the label text was clipped to the button's display size, hiding part of the label. The dialog now takes the label length into account, and makes the buttons wider if necessary to accommodate longer labels.

Changes in version 2.5.9/3.0.8

• The HTML interpreter's table layout rules have changed for cells that span multiple rows and/or columns. In the past, the interpreter divided up the width of a multi-column cell evenly over the columns it spanned, and divided up the height of a multi-row cell evenly over its rows. This made it difficult to achieve certain effects, because it tended to add a lot of extra space to rows and columns that would otherwise have been small. The interpreter now uses a more sophisticated algorithm described in the table layout section.
• A bug in the HTML interpreter caused the interpreter to crash, on rare occasions, when using the Find or Find Next commands. The problem was tied to unpredictable particulars of memory allocation, so it was essentially random - it didn't depend in any obvious way on what game was being played or on what appeared on the screen. This has now been fixed.
• In the past, clearing a banner window created through the TADS 3 banner API stopped any sounds playing in the main window. This no longer occurs.
• <SOUND> tags are no longer allowed in banner windows created through the banner API. Such sound tags were allowed in the past, but this caused various problems, because all windows effectively shared the "sound queues" of the main window - that is, all sounds were effectively coordinated through the main window even when played from banner windows. Any <SOUND> tags that appear in banner API windows will now simply be ignored.
• In the HTML interpreter, going back to review a page (with the "go to previous page" command) incorrectly showed the contents of any <TITLE> tag on the page as part of the page's text. This no longer happens.
• The HTML parser is now more tolerant of missing "close tags" (HTML tags of the form </xxx>). When a close tag is found that doesn't match the latest open tag, the parser now searches for an enclosing open tag that matches; if a matching open tag is found, all of the nested tags are closed. This change generally produces results closer to what was intended, despite the error in the HTML. In particular, when a close tag is missing somewhere within a complex, nested structure like a table or a banner, the change ensures that the larger structure is still parsed correctly, even though its contents have a missing close tag.
• A problem in the HTML interpreter occasionally caused unpredictable behavior, including crashing the interpreter, when TADS 3 banner API windows were used with the "MORE mode" style. The problem only occurred when the windows were layed out in particular ways, so it happened only rarely. This has been fixed.
• "https:" has been added to the list of recognized internet hyperlink prefixes for the <A HREF> tag. (See the <A HREF> documentation for more details.)
• In the Windows HTML interpreter's "Customize Theme" dialog, in the "Colors" page, the Status Line color buttons are now disabled when the "Override game colors" option is selected. When this option is selected, the Main Text color settings are used for everything, so the status line text colors can't be specified separately in this case.

Changes in version 2.5.8/3.0.7

• The HTML interpreter's command history feature (which lets you recall recent commands to the command line, so that you can edit them and re-use them) has a couple of enhancements:
  • On Windows, the F8 key now acts the same way it does in the DOS shell: it recalls the most recent prior command that starts with what's currently on the command line. If you press the key repeatedly, it recalls in turn each prior command that starts with that prefix. This handy shortcut lets you recall a complex past command with just a few keystrokes.
  • The command history now omits a command if it's an exact duplicate of the immediately preceding command. This ensures that the history doesn't fill up with a run of "WAIT" or "AGAIN" commands, for example. Note that this only applies to the most recent previous command; so if you type an alternating sequence of commands (WAIT, AGAIN, WAIT, AGAIN, etc), for example, the entire sequence will be stored in the command history.
• Workbench for Windows now correctly handles the various Edit menu commands (Cut, Copy, Paste, Delete, Undo), and their corresponding accelerator keys, when editing an expression or value in the "Locals" or "Watch Expression" windows. In the past, these commands were ignored.
• The Windows HTML interpreter now understands Ctrl+Insert to mean "Copy," Shift+Insert to mean "Paste," and Shift+Delete to mean "Cut." These accelerator keys were standard in the first few versions of Windows, and while they've long since been deleted from the Windows UI guidelines, many applications still support them anyway because some long-time Windows users are accustomed to them. Note that the modern equivalents are still supported, too, of course - you can still use Ctrl+C for Copy, Ctrl+V for Paste, and Ctrl+X for Cut.

Changes in version 2.5.8/3.0.6

Interim build 2.5.8/3.0.6q: 5/9/2004