Gregor.AppCore
Sunday, April 27, 2003
Gregor.AppCore namespace
That Welcome Screen
Offers a customizable splash screen that can be used at application startup. It can also display "Did you know ..." tips read from a text file.
Background Worker
Then, there is a class that encapsulates worker threads (including aspects such as thread synchronization, cross-thread exception handling, in-progress notifications, and cancellation), as well as a cooperating form showing a progress bar, that can be displayed modally and non-modally.
Templating
WebEdit.NET's parameterized templates feature uses this namespace as well.
Gregor.AppCore.Documents namespace
Wrapping Document Logic
Provides abstract representations of documents, separating document state, presentation, and storage. Supports multiple documents as well as a hierarchy of documents. The chief goal here is to wrap up typical algorithms and patterns needed by an application that lets the user create, load, edit, and save documents. There is the notion of a "dirty" document (needs to saved), loading a file as a template (without keeping storage info), making a backup (not changing storage location), "save as" and "insert" operations, asking the user to save document, and so on. A document can have multiple views (although the content model update strategy is not the one of the MVC pattern).
Gregor.AppCore.Extensions namespace
AddIns
Provides AddIn functionality with the CAddIn class, which supports dynamic loading of assemblies at runtime. CAddIn objects are kept in a special collection; there is also a special setting class (see below for settings) that makes it a breaze to provide for AddIn setup by the user.
AddIns may be provided by third parties and consist of a class library. This class library must be linked against AppCore.dll, and will typically also reference assemblies provided by the application; it must have one class that implements the IAddInConnector interface. The CAddIn class exposes an instance of the class that implements the latter interface (instantiated by reflection). It also holds an instance of System.Reflection.Assembly, which represents the AddIn class library.
If an application integrates VSA support (wrapped up in the Gregor.Scripting project), it can make the AddIn available in the script engine, in order to allow user-defined customization of the AddIn.
Assembly Browser
This namespace is also the home of the Assembly Browser, which is used in Gregor.Scripting as well as in WebEdit.NET. It lets the user poke into any .NET assembly. Here are a few of shots of the Assembly Browser 1 2 3 4 5 6 7.
The assembly browser has the following features:
- There is a list of recently visited assemblies.
- There is a tree view for the assemblies, namespaces, and types, and a list view for type members.
- For each assembly, all references are listed.
- There is a history of types visited (but not members, purposefully).
- All types and members are available, even private ones.
- Types are grouped into namespaces.
- Base types are shown in tree nodes directly under the respective type node.
- Alternatively, the tree view can be arranged according to the type hierarchy in each namespace, with modules, System.Object and top-level interfaces directly under the namespace node, and derived types under the type nodes.
- Both the type tree view and the member list view allow grouping by type/member kind.
- There are navigation shortcuts (not shown in the screen shots) to the types associated with each member, such as return type or parameter types. Assemblies containing the definition of these types are automatically shown when needed.
- There is a search facility for types (partial matches on the names of types in selected assemblies work as well as fully-qualified names for types in any assembly).
- Members may be searched or filtered using wildcard expressions.
- Members may be filtered by visibility and scope.
- The member list may show inherited members, even for interfaces.
- For optional/default parameters and enum members, the initialization expression (or underlying value, respectively) is shown. For flags enum members initialized to a combination of enumerators, that value is shown in decomposed form.
- If a member implements an interface member, either the Implements clause or a comment is shown in the details pane.
- There are options to show either simple type names, fully-qualified type names, or language-specific type aliases.
- For enum types, the underlying integral type is shown.
- An option exists for either showing or hiding default modifiers.
- There is extensible support for multiple programming language syntax. The user may switch between the different languages. The Gregor.NET framework supports for C# and VB.NET syntax.
- The browser recognizes modules (C# static classes, VB.NET standard modules), and displays them appropriately.
- Generic types and methods are supported as well.
- All custom attributes on assemblies, types, and members are shown.
- Obsolete (deprecated) items are shown in strikethru fonts.
- Descriptions applied via certain custom attributes (such as Gregor.Core.DescriptionAttribute or System.ComponentModel.DescriptionAttribute) are available in the details pane.
- Whenever an item is selected, a custom callback is invoked, which allows collecting more information (such as XML documentation) for display.
- All the information selected is available for a hosting application, which may provide extra services.
The assembly browser is easy to integrate into an application. For an example of standalone-use, see the AssemblyBrowser tool from the FileTools collections (on the downloads page). For advanced use, look at the WebEdit.NET sources (see the CCodeAssistanceContextMenuProvider class).
Gregor.AppCore.FileSystem namespace
File Types, Filters, Programs
This one deals with wrap-ups of file types (extension, description), file system filters (which can be arranged in a hierarchy), executable programs (exe path, friendly name). Some classes cooperate with the Settings namespace in this project.
Gregor.AppCore.Settings namespace
A Comprehensive Approach to Configuration
Deals with program settings - from a simple boolean switch represented by a checkbox to complex tree structures. Classes derived from CSettingBase take care of converting to and from an XML representation of the setting, displaying appropriate controls in the dialog provided, and manage default values (including reacting to a "reset" request) as well as cancellation of pending changes the user has made in the dialog.
The dialog provided shows a tree view on the left side (the nodes representing instances of CSettingGroup), with one or more settings belonging to each group shown in a scrollable control on the right side.
The application can listen to changed settings by subscribing to an event. The program also decides where to store the settings XML file.
Simple Program Options
For simple program options, an application can retrieve string, boolean, or integer options from an XML file with a single function call. These options can be nested, allowing for hierarchical data.
Gregor.AppCore.ShellControls namespace
Cloning Windows Explorer
These controls let you build a Windows Explorer replacement. They use the WinShell assembly for that. The XShellTree view can display the entire Windows Shell namespace, or have any arbitrary folder as its root. It's also possible to display file names in the tree (for example, if you want to display the Windows favorites). The XShellList view can show both folders and files, or files only. Furthermore, a file filter pattern can be applied. The list view supports the Shell's sort order (folders on top, with special, non-lexical, ordering).
Drop Me, I'm a Control
There are also dropdown controls, including folder/file tree views, file list views, color pickers, and potentially more. The ultimate base class here is XDropDown control, which offers an icon and a textbox in the fixed portion, and allows placing anything (controls, owner-drawn UI elements) in the dropdown portion. There are also the generic XDropListView and XDropTreeView controls. The latter is extended by WebEdit.NET for its file filter hierarchy combo tree.
Comboing
The XComboBoxEx control offers adding items by most recent usage (ensuring all items are unique), adding items in a sorted order, and auto completion. All of these operations may be performed with or without regard to case. There's a property that gets the window handle of the underlying edit control (this is useful if you want to use the Shell's auto completion features [SHAutoComplete API]).