Overview

MADCAT stands for Multipurpose Application for Data Collection And Treatment.

It is an empty application which can be configured to manage any kind of data the way you want. This application provides the common functions any data management program should have :




So to build a powerful application, the only thing you have to do is to focus on your data and what you have to do with it. You'll have to :



MADCAT is based on XML for data management, XSLT and HTML for reporting. Good knowledge of XML is recommended to be able to start a new database from scratch.


Advanced users who have knowledge of C++, XSLT and HTML can even develop their own type manager, renderer and tool using the Microsoft .NET framework. MADCAT provides specific interfaces for these elements.


To discover MADCAT, this overview will show you step by step how XML configuration files are interpreted by MADCAT. The overview is based on a real application : The MADCAT's workspace Editor. You'll see how the Workspace Editor has been made. Presentation is made with few words but simple diagrams. A more complete reference manual is available in PDF, CHM and on-line.

MADCAT Tour

Welcome in the MADCAT Tour !

This tour is composed of 3 main parts :


MADCAT user interface

The user interface of MADCAT is very simple. Only useful items are shown. Every item which can't be activated is hidden.
It is composed of a main window which can have one or more child windows (MDI). Each child window is an explorer of a database.




Three secondary windows are also available :

  • Logbooks : to view messages produced by MADCAT and the tools
  • Configuration panel : to edit the user's preferences
  • Process manager : to control your treatments



These elements are described in the following child pages :

Main window

Available databases are listed in a tool bar placed on the left of the main window.
On the top of the main window, you have 3 different interfaces :

  • The main menu
  • The MADCAT tool bar
  • The tool bars of the tools of the active workspace (one or more bars)






End-user can change the appearance of any button bar with a context menu displayed on right-click. Their position in the main window can be changed too.
The user can also hide/show any tool bar with a context menu displayed on right-click event on an empty sector of the tool bar area.


The main menu

This menu gives you access to :

  • Workspace and project : you can open a new workspace, save your changes on disk or quit MADCAT
  • User preferences : you can change your settings.
  • Baselines (when activated by the workspace) : you can create baselines or navigate in your baselines
  • Reports (when available in the workspace) : Run a report and print the result
  • Logbooks : View the messages produced by your workspace
  • Actions (when available in the workspace) : Run a treatment
  • Help : Find infos concerning the workspace or MADCAT



The MADCAT tool bar

This bar gives you a quick access to the most important functions of MADCAT :

  • Opening a workspace
  • Save data of the project
  • User preferences
  • Find an item in the project
  • Reports
  • Logbooks
  • Process manager



Tool's bar

Each loaded tool has its own tool bar displayed on the top of the main window. The bar is filled with buttons. Each button is attached to one action of the tool. Action is run by clicking on a button after selecting the items in an explorer window.
Buttons are enabled/disabled depending on the current selection and the model of the workspace.



Databases bar

This bar contains one button per database. A database is the data repository managed by one model of your workspace. Each model has its own database. Click on a button to open a new explorer window on a database.



Explorer window

The explorer is composed of 3 elements :

  • Button bars placed on the top of the window
  • A tree
  • A display area



The explorer is attached to one database (one XML file defined by a model). It is the only window used to navigate in your project and perform actions on it.
Users can open several explorers at a time. Different explorers can be attached to the same database.



MADCAT doesn't save the layout of the child windows. Every time MADCAT is started, the main window is empty and you have to open the explorer windows manually. But the position and the size of each window is saved. So when you open a window, it will always be displayed like you left it before.


Button bars

The explorer has its own button bar which contains a button for each major action :

  • Go to parent item
  • Print current selection
  • Edit current item
  • Delete selection
  • Copy/Cut/Paste
  • Find an item
  • View item's history (when baselines are active)
  • Find where an item is linked
  • Follow a link
  • Create items


It has also a button bar for the renderers. Each renderer has a drop down button. The button shows the different display modes of its renderer. User can change the renderer or the display mode by clicking on these buttons.
Renderers may also add their own buttons in this bar. Each button is used to control specific functions of the renderer. Their behaviour won't be explained here as it is totally dependent of the renderer.

Tree

The tree shows the major items of the database (the ones which have children items). You navigate in your database by clicking on the nodes of the tree. The tree controls the content of the display area.
Users can also perform drag'n'drop on the tree.



Display area

The display area is the area controlled by the active renderer. Its content may be different from one workspace to another.
By default, MADCAT has one renderer which supports 4 different rendering modes. See chapter "Default renderer" for more informations.
The area is used for the selection. It can be a single item or a group of items.
Users can also perform drag'n'drop on this area.



Logbooks

MADCAT manages different types of messages and each message is logged with the following information :

  • Date and time
  • Tool which has produced the message
  • Context of the message (name of the action which has produced the message)
  • Type of the message. It can be : Information, Warning, Error, Confirmation or Question
  • Text of the message
  • Help concerning the message
  • Additional information about the message




As tools can produce many messages at a time, MADCAT uses logbooks to display them. Logbooks are views of messages.
They are defined by the end-user who can set several filters :

  • Author of the message
  • Context of the message
  • Type of message






Each end-user has his own logbooks. He can create/delete them at any time. This has no effect on the messages memorized by MADCAT. All messages are kept in memory until MADCAT is shutdown but content of a logbook can be saved in a XML file in real-time or on-demand.

Here is an example of log file : madcat.xlg

User preferences

MADCAT can manage user preferences for the following elements :

  • a database
  • a tool
  • a renderer
Please note that the triggers of a database are configurable. The user can disable/enable a trigger by opening the settings form attached to a database.

When one of these items afford user settings, they are accessed through the configuration panel of MADCAT :



The user clicks on the element and the settings attached to it are displayed in a form the user can edit.




User settings are saved in a binary file which is stored in the folder "Application Data/MADCAT" of the Windows user folder "Document and settings".


Process manager

The process manager offers a form which lists the actions terminated or running.
The user can view the progress of the running actions. He can also pause all actions or cancel all of them (if the action supports these features).
He has also access to the process control form which will gives him a detailed information :

  • Start time
  • Estimated end time or Total duration time if action is terminated
  • The status : Running, Ready, Cancelled, Successfull...
  • The logbook of the action where he can view all the messages produced by it






This form also affords the user to pause, cancel or restart an action. These functions may not be available for all actions. Functions supported by an action are defined by the tool definition file written by the designer of the tool.

Note that the title bar and the status bar of the main window of MADCAT indicate the number of running actions and the overall progress.

Workspace

Definition

MADCAT runs workspaces. A workspace is a set of 4 major types of elements : Models, Types, Renderers and Tools.
In addition the workspace contains secondary elements like : folders for data storage, bitmaps, stylesheets, etc...

Workspaces are defined by XML files with extension XWS. Files are called "workspace definition files".

MADCAT can be associated to XWS files to run directly workspaces from the Windows explorer. Otherwise a startup menu let you choose the workspace to run.

A XWS file defines :

  • the workspace name,
  • the location of the models,
  • the location of the user-defined types,
  • the location of the renderers definitions (XRD files),
  • the location of the tools definitions (XTL files),
  • the location of the data storage (Project folder),
  • the current baseline,
  • the splashscreen settings,
  • the background settings,
  • the help file location,
  • and the icon of the application


Application

So let's start with the Workspace Editor. Our work will be divided into 2 main work packages :

  • XML configuration : Creation of all the XML definition files needed to define our data, tools and reports
  • Tool development : Creation of the libraries (dll) needed to process actions on our data


Requirements

Your mission is to built an application which will help you create new applications ! We want something that will produce new workspaces without having to write XML files.

Development

First, build the workspace of this application. Then, take a look to the API to develop the tools which will generate new workspaces.

Create the space for the application in your filesystem

First we need to create a folder for our workspace with specific sub-folders inside. The mandatory sub-folders are :

If you use theses names, your XWS file doesn't have to mention the locations of MADCAT elements because they are the default names. You can even skip the XWS creation step ! MADCAT recognizes such structures and try to run without XWS file.

It is recommended to add the following folders :

Initialize the XWS file

Create a text file named "Workspace.xws" in the root folder of your workspace and type the following text inside :


Place the following bitmaps in the "bitmaps" folder :

splashscreen.png

This bitmap will be displayed for 10 seconds at start-up. It is the "splash screen" of the application. It disappears before the timeout when user clicks on it.

workspaceeditor.png

This bitmap will be the icon of the application. It will appear in the title bar of the window, in the task bar of Windows and in the "About box" along with the author's name and the description written in the XWS file :


Fill your workspace !

Now, the application can be started by doucle-clicking the XWS file in the Windows Explorer :


Splash screen appears, the title and the icon are OK but we have nothing in it :

All the tool bars are empty except MADCAT's one. No data can be managed. So, now we have to build models.

Model

Definition

The model is a database definition. It explains MADCAT how data is organized, how it should be presented to the user (input forms, display sheets, etc..) and how users can interact with the data. Models are defined with XML files. One model defines one database. Databases are made of :



A workspace can manage more than one model. Using links, models can share data without duplicate.


All the data produced with one model is stored in one XML file.

Application

Create the model for workspace files

We'll start by creating the model of the XWS files.
Download the file below and place it in the folder "Models" with the name "workspace.xml"

workspace.xml


This file contains the definition for only one item named "Workspace". This item has many attributes and links to other items of other models. The diagram below shows you the way it is interpreted by MADCAT :

You can also re-run your XWS file. You'll see this in live ! Now we can create some data. Check the "Project" folder, you should have something like this :

Create the model for all the other files

Download the file below and place it in the folder "Models" with their original name :

model.xml
tool.xml
report.xml
renderer.xml

Your workspace files shall look like this :

and now, if you start you XWS again, you'll see that the tool bar has many items inside :

Add some nice icons

Now, place these additional bitmaps in the "Bitmaps" folder :



file.png

database.png

folder.jpg

link.png

mode.png

query.png

renderer.png

report.png

tool.png

workspace.png

and check the result :

Item

An item is an XML element. In our example, items are defined in the models :

They can be created, edited and deleted with the toolbar of the model explorer of MADCAT :

Attribute

Atomic piece of data. Owns the values attached to an item. Attributes may have various types; each type is linked to a default input field and display format.
MADCAT manage the following types :

  • String
  • Text
  • Numeric
  • Date/time
  • File
  • Bitmap
  • IP Address
  • Groups
  • Enumerate
  • Boolean



The form is generated using the parameters defined in the model. MADCAT creates one field per attribute in the edit form of an item :

Each value of an attribute will be stored in a real XML attribute of the XML element created in the project data :


Advanced user can also create their own types of attribute by using the interfaces of MADCAT. The associated field iand the way the value is stored and formatted are then entirely controlled by a library developed by you. See Types section for more details.

Triggers

Triggers are actions performed automatically when end-user executes a specific action on an item.
Triggers are attached to items in models. Possible triggers are :

  • Click : An action is run when the end-user clicks on an item
  • Double-click : An action is run when the end-user double-clicks on an item
  • Drop : An action is run when the end-user drops an item
  • Timer : An action is run periodically. Period is based on the timer definition
  • Before create : An action is run when end-users clicks on a button to create a new item (just before the "edit form" opens). The result of the action can cancel the creation
  • After create : An action is run when end-users has finished creating an item (just after the "edit form" closes). The result of the action can cancel the creation
  • Before edit : An action is run when end-users clicks on the "Edit Item" button (just before the "edit form" opens). The result of the action can cancel the editing
  • After edit : An action is run when end-users has finished editing an item (just after the "edit form" closes). The result of the action can cancel the editing
  • Before delete : An action is run when end-users clicks on the "Delete Item" button (just before the item is deleted). The result of the action can cancel the deletion
  • After delete : An action is run when end-users has deleted an item.



Actions are threads executed by the tools of your workspace. They can be run by clicking a button on the tool bar of MADCAT or activating a trigger. By defaut, MADCAT provides no tools. Only advanced users can create their own tools by using the API of MADCAT.


MADCAT allows the end-user of a workspace to enable/disable a trigger. Future releases of MADCAT will restrict this possibility by using access rights attached to end-users.

Actions

ACTIONS are XML child elements of ITEMS and FOLDERS which indicate the name of the action a user can perform on them.
The actions are implemented in tools. The name specified in the ACTION element must be one of the names defined in a tool definition file of your workspace. If the name refers to an action performed by a tool which is not loaded (unknown action name), the element is discarded without any messages.
This attribute controls the buttons of the tool bar of MADCAT where actions of loaded tools are displayed. When the end-user selects an item in an explorer, only the actions listed with this element in the model of the item are enabled. All the buttons of other actions are disabled. The contextual menu of the explorer is updated as well.

Link

Links are specific items that allow items to have children coming from external database of the same workspace.
They are defined in a model by using the LINK element. When MADCAT find a LINK element in an ITEM or FOLDER element, the user will be able to create links in this ITEM or FOLDER.
In this example, the model is designed such as the user will be able to create links to renderers in the folder "Renderers" of the item "Workspace" :


Data is not duplicated in project storage but in reports and tool treatments :
You can follow a link in the explorer, this will open a new explorer with the focus on the target item :

You can also directly edit a link. You will edit the target item.

When you export the data using a report, the link is automatically replaced with its target item.

MADCAT has a function to find links pointing to a selected item. Select an item, click on the button and it runs a search which will lists all the links refering to your item :

Finally, when you perform an action on a link, the tool will "see" the target item but not the link like reports. It can directly read or edit the attributes of the target item.

Query

This element defines a special folder which doesn't contain items you create manually. It contains items found by executing a standard XPath expression on the current database.
The items listed by queries can be modified or deleted. Just note that they are not real XML children of the "Query" element.

Folder

A folder is a XML element which can contain one or more elements such as : items, folders, queries.
The difference between ITEMS and FOLDERS is FOLDERS have only one attribute named "NAME".

MADCAT manages two types of folders :

  • Folders defined by models using the FOLDER element
  • Folders created by end-users in MADCAT



When defined by the model, folders are automatically created by MADCAT when the parent of the folder in the model is created by the user. The XML element attached to the folder in the project's data has its name specified in the model. They are seen as static parts of the parent item. Such folders can't be deleted, moved or created by the end-user. They can also be attached to actions with the ACTION element.

When created by the end-user, the folders can be deleted, moved, created anywhere in the data hierarchy. The XML element associated to them in the project's data is always named "FOLDER". Concerning triggers and allowed actions, they automatically inherit their parent's properties.

Types

In addition to the base types of MADCAT, advanced users and workspace suppliers can create their own types.
Base types are :

  • String
  • Text
  • Numeric
  • Date/time
  • File
  • Bitmap
  • IP Address
  • Groups
  • Enumerate
  • Boolean



When defining a new type, you have to handle the format, display and conversions of the values assigned with this type.
The API of MADCAT defines interfaces to control types and allow sorting, filtering, display and conversions.

New with MADCAT v1.0d.

Boolean input fields have now several new options :

Numeric input fields have now new display options :


Parameters Demo

To help you try the parameters settings and all the types of MADCAT, I made a demo workspace which allow you to create items having all the different input fields offered to you by MADCAT.
Download and unzip the following package, then run the workspace by double-clicking the XWS file.

ParametersDemo.zip (3 Kbytes)

In the future, a complete documentation will be available. But for the moment, just use the model written in this demo workspace to find the options you can use to build your own workspace.

Renderer

Renderers are libraries (DLL) which provide new controls to display/edit your data. The controls are embedded in the explorer window of MADCAT.
They are written in C++ using the assemblies of MADCAT.

Renderers should be placed in a specific folder of the workspace with their definition files

One renderer can manage many modes. End-user can attach a specific renderer and a mode to an item in a model. He can also change the mode or the renderer directly in the database explorer.

Renderers can also manage user options like tools.

Objectives

There are no restrictions on the controls used as long as the following objectives are satisfied :

  • End-user can select one or more elements
  • End-user can use drag'n'drop
  • End-user can see the elements contained into the element selected in the tree of the explorer whatever its type (it can be a folder, an item or a query)
  • End-user can see at least one attribute of the elements such as its name
  • End-user can see the baseline status of the element when baselines are activated
  • Workspace suppliers can control a renderer with their models (See rendering modes)



End-user can switch from one renderer to another by clicking on buttons in the explorer tool bars.

Default renderer

MADCAT provides only one renderer by default. It is directly embedded into MADCAT's executable file. It is not a DLL.
This renderer supports 5 modes :

  • Icons : Elements are displayed with big icons. The value of the 1st attribute of the element is displayed under the icon
  • Tiles: Elements are displayed with big icons. The value of the 1st attribute of the element is displayed under the icon along with its type description
  • Details : Elements are displayed with small icons. The values of the attributes of the elements are displayed in columns. One column per attribute. They can be sorted or filtered. Columns order can be changed. Columns can be masked or displayed.
  • Vertical : Elements are shown in column. Attributes are displayed in lines
  • Baselines : Elements are shown in group. Columns are different baselines and values of each baseline are shown in columns






The default renderer also provides a embedded form which can be displayed or masked with a specific toggle button in the explorer tool bar. This form can be used to directly edit an item selected in the explorer. It is compatible with all the modes listed above.



Definition File

The definition file is a XML file which comes along with the library (DLL). Its extension is XRD.
It is read by MADCAT during start-up. It contains important elements :

  • Name, icon and description of the renderer
  • Path of the DLL
  • List of the supported modes with their names, icons and descriptions



These information are used by MADCAT to display renderer's buttons into explorer windows of the user interface.

Rendering modes

Each renderer can implement one or more rendering modes. Modes change the style of the display. End-user can change the mode by clicking on the drop-down button of the renderer in the explorer tool bar. The modes are defined in the renderer definition file (XRD).

Special features

Renderers can also integrate new buttons in the explorer tool bar to add new features or control the display.



User options

Renderers can also define a set of parameters which can be changed by the end-user in the "Options" form of MADCAT.
These parameters can control the behaviour of the renderer.



Interaction with models

Workspace suppliers can also define rendering options in their models. ITEM and FOLDERS has specific attributes to control the renderers. With these attributes, you can automatically switch to a specific renderer and a mode when the end-user "opens" an element in an explorer window.



Tool

Tools are programs which can perform treatments on the data of a workspace. One treatment is called an "action".
They can be external programs (.exe) or user-specific libraries (.dll) compatible with models.
Tools are developed by workspaces suppliers. MADCAT has no tools by default. They are based on the API of MADCAT and the .NET framework of Microsoft.
They can access data to create/edit/delete items in your project. But you can also use them to perform treatments on files by using the powerful set of libraries of the .NET framework.
A tool can offer several actions. Actions are attached to items by the model (see ACTION). End-user runs them through the menu or the toolbar of MADCAT's interface.

Tools and their actions are defined in a XML file with extension XTL.

Tools should be placed in a specific folder of the workspace with their definition files

Task management
MADCAT provides a powerful task manager and log manager to execute tools' actions in different threads and trace any events or changes performed to the data. Actions can be scheduled, paused, resumed, canceled, re-run, and so on... in a very easy way.

All database updates are traced and can be checked after action's execution. Transactions can also be canceled when action fails to preserve the database.

Progress display
MADCAT provides to the end-user a very detailed progress window providing global progress, estimated end time, step progress and controls for action execution.




Logbooks
It also provides a logbook system which allow the end-user to capture all events and messages produced by the tools or only specific ones using filters. Logbooks can be exported, transformed in HTML because they are also XML files.




User preferences
Finally, MADCAT provides a user profile management which allow tools to define sets of options users can change freely. Options are automatically saved when user leaves MADCAT and loaded when he enters a workspace.
Each workspace has its set of options. Options are user-dependent (saved in the Windows's user-specific folders)




Definition File

Practically a tool is a DLL (Dynamic Link Library) with a definition file having a XTL extension. This definition file controls the way MADCAT displays and executes the actions supported by the tool : it gives the following information :

  • Name of the tool
  • Icon of the tool
  • Description of the tool
  • Path to the DLL or EXE file
  • List of actions supported by the tool. For each action, you can provide the name, the icon, the description and the execution settings (see below)



Execution of actions can be controlled by several parameters :

  • Background mode : Action is executed in a specific thread. End-user can continue working in MADCAT while action is running
  • Read-only mode : Action can't modify project's data
  • Cancelable : End-user can cancel an in-progress action
  • Suspendable : End-user can pause/resume an in-progress action
  • Endless action : Action has no end. It must be canceled by the user
  • Show progress window : Progress window is automatically displayed when action starts
  • Re-entrant : If set to Yes, same action can be run multiple times in parallel. Otherwise, MADCAT will automatically schedule the action at the earliest moment depending on the end of the currently running threads
  • Multiselect : If set to yes, action can be executed on more than one item at a time. Otherwise, MADCAT will schedule the action once for each item



These settings are defined once for all by the designer of the tool. Changing these settings without changing the tool itself may produce unpredicable results.

You can download the definition file of the tool used by the workspace editor :
WorkspaceEditorTool.xtl

Execution control

All actions are controlled by the process manager of MADCAT. The process manager provides a list of the actions performed or in-progress. Using the process manager, you can :

  • See the progress of working actions
  • See the execution log of terminated actions
  • Control the execution of working actions
  • Restart a terminated action with its initial context of execution


Controls

Depending on actions' parameters defined by the XTL file, the end-user can pause, resume or cancel a running action from the process manager window or from the progress window of the action.


Progress monitoring

Each action has its own progress window which can be displayed or hidden at any time.
MADCAT also indicates the number of running processes and the overall progress in the title bar and status bar of the main window.


Progress windows also provides an access to the log window of the running action. You can see in real-time all the messages produced by the action.

Note that the colors of the lines of the logbook are controlled by the tool using the API of MADCAT

Execution log

MADCAT records several information about each action :

  • Start time, end time and duration
  • The context of execution of the action (XML elements of the project data, input parameters)
  • Data transactions performed by the action
  • Messages produced by the action



All this data can be analysed in the execution log window :



This window can be displayed from the progress window of any action listed in the process manager.

Please note that execution log can't be saved into a file. The log is lost when MADCAT is shutdown. Only messages can be saved into a XML file. See Execution control.

Baseline

MADCAT can manage baselines of your data. Baselines can be seen as read-only snapshots of your data. Once a baseline is closed, the data is saved at the time of closure. You can continue modifying your data but you will always be able to see it at the time of baseline's closure.
It can show you dynamically the changes made between baselines with colors.


When activated, all changes made to attributes values or items are traced. History can be parsed and old values restored easily.
You get a detailed history of the item from the explorer :

The history and the status are dependent of the reference baseline which can be changed with the menu "Baselines" :

The term "The Big Bang" refers to the very beginning of your project; when it was empty !

With the menu "Baselines", end users can also easily navigate through baselines and compare them by changing the reference baseline. Create new baseline from any existing baseline (create a new branch)


When you close a baseline, MADCAT asks you for the name of a new baseline. This new baseline will be a child of the closed baseline.

The history of changes performed in a baseline is saved in a baseline file (Extension is XBL). A baseline file can be loaded at any time. It is also an XML file which can be used to perform analysis and reporting.

The XBL files are associated to a folder having the baseline name. This folder contains the project data for that baseline. They are managed exactly like project data without baseline which are in the root of folder "Project". So if you don't want to use the baselines anymore you can just remove the baseline element in the workspace definition file, move the project data of one baseline to the root of folder "Project" and restart your workspace.

By switching from one baseline to another, you can produce a version tree like this :

Baseline mechanism can be activated or deactivated at any time by modifying the workspace definition file.



Report

Report is a XML file which defines a standard XPATH query to execute on the databases of a workspace and a XML stylesheet (XSLT) for formatting. Extension is XPT.
The ouput can be HTML or XML. End-user can save it into a file.


This report has been generated by MADCAT using this definition :

which can be downloaded here : report.xpt along with the XSLT file which converts the XML to HTML : wrkspc_list.xls


MADCAT loads report files on start-up. End-user can produce reports from MADCAT's user interface.


Reports can use input parameters to control the content of the report : the values of the parameters are used in the XPath expression.
For example, the Report definition defines one parameter :


This XPT file can be downloaded here : report2.xpt
Note that the XPath expression refers to the parameter name with the delimiters %%
When users runs the report, a form opens to request the parameter value :


The report is generated if user enters mandatory values and click on "Generate"


Here is the XSLT file used to format the report : wrkspc_list_renderer.xsl

API

API of MADCAT provides a set of services for :

  • Message log (errors, warnings, information)
  • Database updates on a transaction basis
  • Dialog boxes for user interface : Wizard, query box, confirm box
  • Import data from the clipboard to the workspace
  • Export data of the workspace to the clipboard
  • Support drag'n'drop events with external programs.



With this API, you can enhance your workspaces and build :

  • Tools to perform treatments on your data or read/generate files on your system
  • Renderers to display/use your data
  • Types to control, manipulate your data



Click on the following links to see an overview of this :

Renderers

Download the following reference manual to learn how to code a renderer.


To build a renderer you will need the following assemblies :

  • RendererInterfaces
  • Parameters


Tools

Download the following reference manual to learn how to code a tool.


To build a tool you will need the following assemblies :

  • ToolInterfaces
  • Parameters


Types

Download the following reference manual to learn how to code a type manager.


To build a type you will need the following assemblies :

  • Parameters