[AppCore]

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:

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]).