The most important new features, in the .NET versions, are:
Improved features include:
WebEdit.NET charmes the user with a fresh new user interface. While anyone used to the classic UI will feel right at home, the atmosphere is much more relaxed and friendly. You'll find icons in many more places than before, even in menus, which are owner-drawn. Menu items are now consistently disabled if a given action is not available. Look at this.
The toolbars can be customized. This includes buttons for starting macros (see below), as well as buttons created by AddIns (see below). Button appearance is as flexible as it is in Microsoft Office.
The most obvious novelty in WebEdit's user interface are draggable and dockable tool
windows. You can easily hide and show them, using toggle buttons like those in the
Windows task bar. Each tool window provides access to additional functionality. Here's the
History tool window, which now supports sorting/grouping entries
by date, by name, by file type, or by site.
Other toolwindows offer file system functionality, FTP features, searching files or text,
token management, or display the Windows Favorites. In this version, every toolwindow has
its own toolbar with addtional commands.
Tool windows can be arranged so as to split the screen between the editing pane and the tool
window, or they can hover above the editing pane, hiding automatically when they lose focus.
Addtionally, they can act as non-modal dialog windows (along with an in-place minimize feature
called AutoCollapse), or fill the entire window (MDI child windows). Tool windows can even be
main windows, shown in the Windows Taskbar.
With an AddIn (see below), you can even create your own tool windows that fit
seamlessly into the user interface, offering custom functionality.
WebEdit supports multiple documents - as an option. Navigation is easy using draggable tabbed documents, like in Visual Studio. Look here. WebEdit keeps a per-window history in each document window, preserving the familiar web browser behaviour (this is the same as in the VS.NET help viewer). The user controls when new child windows are opened, only restricted by sensible base rules (like taking into account the case where a document is already opened in another window, the case of a dirty document, and per-window history navigation).
The (per-window) history remembers the selection and scroll position in a document, making it easier to switch between specific locations in several documents.
Through AddIns (see below), WebEdit.NET is capable of fetching documents not only from the local disk or a web server, but from any source, such as databases. Similiarly, documents may be displayed in different forms, such as Hex View.
When opening a template or inserting the contents of a file, WebEdit parses the text for placeholders marked by special expressions (for example, "$StyleSheet%"), and prompts the user to fill in values for these in a dialog box. The values are saved for subsequent suggestions, using the Shell's AutoComplete features.
WebEdit's parameterized templates support calling methods and properties of loaded assemblies, using the applications new Code Interpreter (see below). This means you can insert the current date/time and other calculated values into new documents. Macros provided by AddIns (see below) may also be called from a parameterized template.
Templates can be loaded from various sources, such as local files or HTTP URLs. A special XML file configuration file (WebEditTemplates.xml) lets you customize the "Open Template" and "Insert Template" dialogs with the paths to your favorite templates.
Both the AutoText and Insert Token features make use of so-called token lists. Token lists can be employed in several useful ways - as a temporary or permanent storage for words, text-blocks, for auto-completion, or for enhanced text replacement and insertion tasks.
Token lists may be read in from any text file (with line breaks as separators). These could contain project-specific identifiers, typical language constructs, your contact's e-mail addresses, or any information that you'd like to use in a document.
Then, there are several pre-defined token lists which don't use files. For example, the Clipboard Ring holds an unlimited number of tokens usable during the current session, at its simplest functioning as a multiple clipboard. There's the Code List, which contains keywords from any language that a syntax parser exists for (see below for syntax coloring), as well as identifiers from .NET assemblies. Finally, WebEdit can split a document's text into a token list. One might also think about hooking up database tables as the source of a special token lists (using an AddIn).
The Token Window is implemented as a tool window. It supports drag-and-drop, as well as keyboard shortcuts. You can load, edit and save token lists in a straight forward fashion, directly in the tool window. When inserting a token from the Token Window, there are several interesting options, like wildcard replacement, unescaping C-style escape sequences, or even substituting parameters: this works in the same way in the parameterized template function discussed above. This makes it a breeze to write a custom text insertion dialog in one line of parameterized text. You may also combine calls into methods with wildcard substition (thereby using the current text selection as a string argument to a method: an example would be a translation macro). The most advanced option here is using regular expression for replacements in the selected text (using the Replace method of the RegEx class).
The AutoText feature now models Visual Studio behaviour more closely. As mentioned, you can choose any token list as the source of AutoText entries. Try automatic recording of words (as you type them in) for later use in the Token Window, by sharing a common token list between AutoText and the Token Window. Or, vice versa. You can also combine several token lists for use in AutoText.
AutoText completion features recognition of escape sequences and parameter substitution. This means you can insert multi-line text blocks (like properties, class declarations, or try-catch blocks) directly from the AutoText dropdown list in the editing pane, completing values in a dialog as needed.
For given file types, users may specify the use of one or more AutoText lists stored in files. These settings are stored in a special XML file configuration file (WebEditLanguages.xml).
Hyperlink detection is still based on quotes (single and double) and angle brackets. But alternatively, the current selection can be used as a basis for opening links.
WebEdit.NET has learned a bit about URLs, and is more tolerant of malformed addresses, such as missing slashes at the end of a directory path.
The address bar now offers the Shell AutoComplete dropdown list that was first introduced in Internet Explorer 5. This makes it a breeze to enter URL or even local file paths, especially when the exact spelling isn't known. It's yet another way to open documents quickly.
Syntax coloring is available for a number of languages, including VB.NET, C#, C++, Java, and HTML/XML. More languages will follow, but note that with an AddIn (see below), you can easily write a custom syntax parser, and add support for any language you like. Here's some colored VB.NET code.
Users may also specify the use of special syntax parsers (provided by AddIns and instantiated via reflection) for given file types. One such parser is the keyword parser (implemented in the Editing assembly of Gregor.NET), which is aware of user-defined keywords. These settings are stored in a special XML file configuration file (WebEditLanguages.xml).
When searching for text in the current document, WebEdit displays a list with all the hits. You move back and forth by using that list. The functionality is provided by a tool window.
For quicky text searches, try the Find Text combo box in the toolbar, or type a command of the form "find:MyText" (see below for the command model).
Both the Find Text window and the Find Text toolbar combo box uses the Shell's AutoComplete feature for suggesting recently used search/replace tokens.
You can choose a custom text font and text/background colors. There's a selection margin for easier multi-line selections. There are new commands to copy either the saved or the loaded version of the current document to a specific location in the file system or at an FTP site (without changing the current document). Printing features include page setup and print preview.
The file manager now fully displays the Windows Shell Namespace, which means that you can open such things as printers or control panel applets. For every shell item shown in the file manager, you can invoke shell commands known as "verbs", such as "Open", "Print", "Explore", or other registered verbs. Besides that, the Shell's context menu is available for any given item.
Optionally, the folder tree can be hidden and folders be shown in the file list instead, offering an alternate file system navigation model. When folders are shown in the list, there's a drill-down feature that lets the user view the contents of several folders at once (the file list is actually a mix of tree view and list view). The file list also supports grouping of items (somewhat similiar what the Windows Explorer does in WinXP).
In addition to browsing the namespace from a specific folder (other than the Desktop), you can choose a Home folder, as a special navigation target.
Links to folders that exist either on the Desktop, in the Start Menu or in the Favorites can be collected automatically and displayed for ready navigation. These folder links are also displayed in file system related dialog boxes.
The file manager can split the tree and the list horizontally instead of vertically (there's also an option to switch between vertical and horizontal layout automatically, depending on ratio of the tool window's width and height).
Like the Windows Explorer, the file manager has its own history of folders visited, supporting multiple-step jumps. If you wish, the file manager can reapply file filters you've set for a given folder.
The dropdown portion of the filtering combo is now a filter tree, which makes creating a custom file filter hierarchy much easier.
The File Search tool window remembers previous search criteria, which allows easy redoing of previous searches. When searching for text in files, there are two new options: match case, and match whole word.
In the Windows Favorites, you can link anything that WebEdit tackles, such as documents, even custom storage documents (see below), local and FTP folders, and any other command. WebEdit can show IE's Organize Favorites dialog by the click of a button.
The directory/file structure of an FTP server is preserved in an XML cache. The FTP tool window uses color-coded items to indicate the status of a folder (new, cached, or updated). You can choose how and when the cache is used.
You can choose whether to connect via a proxy server, set the transfer mode (ASCII, binary, or unknown), select an encoding for remote files, control cache usage, as well as set up concurrent accounts for different users at a site.
Files can be downloaded from a site without opening them. Vice versa, you can upload any file from you local computer.
Just as in the file manager, there is a list of shortcuts to FTP folders (collected from internet shortcuts in the Start Menu, the Favorites, and the Desktop), as well as a folder/filter history.
For slow operations, there is a progress dialog, which allows cancellation. Connections to a server are made automatically. Like in the file manager, you can hide the server and folder tree and show folder in the file list, or arrange both controls horizontally or vertically.
You can manage a group of related files in the project tool window. It supports local files (referred to by relative paths), FTP files, HTTP documents, and even custom storage documents (see below).
Furthermore, any textual command (see below) can be associated with a project, such as building or starting an application. It's also easy to add tokens, or text snippets, to the project.
The built-in assembly browser lets you inspect any assembly loaded (like the Object Browser in Visual Studio).
From the Assembly Browser's context menu, several code generation commands are available (the output goes to the Output tool window as well as the Clipboard Ring token list):
Types in the assembly browser may be linked in the Favorites, the Project, or the toolbars. Textual commands of the "type:" protocol may be used to quickly navigate to a given type.
See the Gregor.AppCore project docu for more details on the assembly browser.
With a menu action or textual commands, you can invoke command line tools for the current document, the group of open documents, or the current project.
If you prefer the keyboard over the mouse, you can enter into the address bar the location of a document, or a command (such as "doc:new"). Although WebEdit isn't the vi (and does not attempt to be), an extra keystroke (F2) will get the application into command mode by setting the focus on the address bar.
The preferred way for working with commands, however, is the Console toolwindow, featuring a command history.
Commands can trigger menu actions, manipulate the UI, invoke macros (in AddIns), control file system navigation, open documents, call the code interpreter (see below), help edit documents, and so on. A major point is that you can use an AddIn in order to write your own command handlers for custom commands. Custom commands play a central role in WebEdit's new extensibility model (see below), in that they offer quick access to AddIn features (for example, opening documents from custom data sources). For power users who are stenographically inclined, there are many interesting options.
In addition to commands typed into the console or address bar, WebEdit.NET treats every command line parameter in the same way. This means more control over application start-up. Likewise, hyperlinks are implemented as commands. The result is a consistent and extensible user interaction model that goes beyond the graphical user interface.
A noteworthy example of what commands and the Console are for is WebEdit's built-in code interpreter, which is based on the .NET Console component. It's an interactive shell based on C# (for now) syntax, executing one statement at a time. It uses reflection to create objects, manage references to them, and to call properties and methods. Any of WebEdit's loaded code is yours to call, without needing to write an AddIn. You can also call your macros from the code interpreter (that is useful if you need to provide function arguments). The interpreter supports ad-hoc inspection of types (that is, it can list its members), lets you keep variables and load assemblies, and prints results to the Console tool window (type "code:help" into the latter to get started).
Third parties as well as users can enhance WebEdit.NET's feature list by creating a managed class library. Since WebEdit.NET provides all of its functionality in a DLL (Gregor.WebEdit.dll), AddIn writers can reference the latter and are not limited to any specific area of functionality.
WebEdit.NET is an extensible application. AddIns can achieve most of what I could do as WebEdit's author. AddIns are suitable for quick solutions with macros as well as for providing complex, easy-to-distribute enhancements to the application, for example, providing access to addional data sources, replacing the FTP/HTTP client functionality with a different implementation, setting up complex toolwindows, or providing alternative document views.
AddIns are easy to set up and require no programming knowledge from the user. WebEdit.NET supports smooth integration, ranging from placing custom actions (with icons and all) onto the toolbar, over showing additional toolwindows, over configurability using the settings dialog, to recording custom-storage documents to the application's document history. An AddIn may be started or stopped at any given time.
AddIns may provide macros. While you can write an AddIn in any .NET language, WebEdit.NET offers special support for C# and VB.NET with a feature called "Script AddIns": You can write a module, one or more routines, or just a code snippet in a editor window, and let the application handle the details of assembly references, compiling, and installing the AddIn. This makes it as easy to use macros as in MS Office applications.
Note: Script AddIns, which are implemented with the System.CodeDom functionality, replace Visual Studio for Application (VSA) as the scripting/macro engine, which has been available in earlier versions of WebEdit.NET.
By default, any public static method of public AddIn-defined types is considered a macro that the user can invoke, provided there are either no parameters, or all parameters are either strings or so convertible. In the latter case, a special dialog pops up for the user to enter values. This way, AddIn authors may offer custom functionality without writing a user interface.
Macros can be invoked from the macro window, and via a menu action. You can also put shortcuts to macros on the toolbar. Finally, a macro can be invoked by a command of the "macro" protocol, which means you can store macro calls in the favorites list, or in a project file.
There are some key parts of WebEdit functionality that you can extend or even replace with AddIns. Your options include:
There are also a few Default AddIns available.
See Also: Version History | Glossary
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}