[prev] [up]

Other Tools

This document is unfinished - there a quite a bunch of other tools to be documented ...

Index

Transcript - The Smalltalk Messages Window

In smalltalk, the Transcript plays the role of a console, where useful information is sent to. For example, the compiler outputs progress information onto the transcript when compiling methods from a file or from the browser.

From your programs, you can send output to the Transcript via the messages: show:, cr and showCR:.

Here are a few concrete examples (click to execute):


   Transcript showCR:'Hello World'.

   Transcript clear.
   Transcript show:'The time is '.
   Transcript show:(Time now).
   Transcript cr
or:

   Transcript show:'The time is '; show:(Time now); cr
or:

   Transcript
      showCR:('The time is %1, today is %2'
		bindWith: (Time now)
		with: (Date today) )

In very old Smalltalk versions, the Transcript and Launcher (described below) were two separate applications. Today, these two applications have been merged into a new Launcher.

NewLauncher - Combined Launcher and Transcript Tool

The Launcher allows startup of commonly used tools and utilities, and contains the transcript window for messages to the user.
This application offers pulldown menus and buttons to open useful applications, monitors and to perform most common operations.

In addition, the language, viewStyle and compiler settings can be set via more convenient dialogs (in previous versions, these had to be set by evaluating Smalltalk expressions in a workspace or by editing the startup scripts).

The launcher is typically started from your "private.rc" startup file.

[missing fig.: newLauncher hardcopy]
Screenimage of the Launcher with a "motif" view style.

Starting with ST/X rev 3.3, the Launcher was completely rewritten, using the new UI-builder framework.
The items found in the pullDown-menu and the toolBar panel can now be changed using the convenient menu-editor; i.e. it is very easy to create a user/project specific subclass with different functions offered.
Also, the launchers functionality was moved to an abstract generic launcher superclass, which does not provide any GUI, but is purely functional.
This architecture allows for future- and custom launchers to be build easily.

Settings Dialog

Use the launcher's settings dialog to change, save and load your personal preferences and settings. The initial setting values are loaded from a file named "settings.stx" in either the current directory (where ST/X was started), or under the ".smalltalk"-subdirectory under your home directory.

The settings dialog operates on the current setting values, which are only valid during the current ST/X session. I.e.: if you forget to save your settings to the settings-file, these changes are lost when you exit Smalltalk/X.

Settings you may want to Change

Two area are of special interest:

Workspace - A Tool for Expression Evaluation

Workspaces allow smalltalk expression to be entered and evaluated.
You can also use them as scratchpads or notepads for ordinary text.

[missing fig.: Workspace-screenshot-1]

Beside the general text editing features, Workspaces allow for Smalltalk code to be evaluated (interpreted). To do this, select some text (which should represent a valid smalltalk expression), and use one of the following popup- or toolbar-menu functions for evaluation (*)

(*) In fact, if nothing is selected, the current cursor line is taken. Therefore, most of the time, you simply have to enter an expression and click on one of the evaluation buttons, or press one of the shortkey commands as listed below.

There are also keyboard shortcuts for the above function - typically "ALT-d" , "ALT-p" , "ALT-i" and "ALT-Shift-B". Depending on your keyboard settings file ("keyboard.rc"), the key assignments might be different on your particular system. If in doubt, look at the right-button menu or consult the Launchers System-Settings-Keyboard dialog.


An ongoing expression evaluation can be interrupted and a debugger is opened by pressing the Interrupt key, "CTRL-c" ("Break" or "Untbr" under Windows).
By pressing the Abort key, ("CTRL-y" or "CTRL-Break" under Windows), an ongoing expression evaluation can be aborted (without going into a debugger).
Aborting means: 'raising an AbortSignal', which is cought in all views' eventLoop.

Starting with release 4.1 of ST/X, workspaces support multiple pages (aka "buffers" or "tabs") and a pull down menu, with additional functions:

In addition, WorkspaceVariables and DoItVariables have been added:

The workspace menu contains items labeled "Auto Define Variables", which can be checked to force all unknown variables to be automatically declared as workspace or doIt variables.
If this option is turned off, undefined variables trigger an error message, as usual.

Evaluation Workspace

A special variant of the workspace is the so called "Evaluation Workspace". This adds a separate view to show an evaluation's result, a list of currently defined workspace variables, and the last few results in a history list.
The evaluation workspace can be opened from a regular workspace's pull down menu.

SharedPools

The set of sharedPools which are visible inside a doIt evaluation can be controlled by the "Add SharedPool" and "Remove SharedPool" menu functions from the "Workspace" section in the main menu. Initially, no sharedPools are visible in a doIt evaluation.

MyWorkspace: a Private Page in the System Workspace

You can add a private personalized page to the system workspace, by creating a file named "MyWorkspace.wsp" in the ST/X startup directory.
There, you may keep commonly used expressions/doIts to start tools or applications.
If such a file exists, the WorkspaceApplication automatically adds another page to its tab-list and presents the contents of that file there.

Multiple Private Workspace Pages

In the 6.2 version, this has been extended to support multiple such private workspaces. To do so,
  1. save the contents (using the "save as" menu function) into the ".smalltalk" folder in your home folder.
  2. add a bookmark (using the "bookmark-add bookmark" menu item).
Now, whenever you open a "myWorkspace", all of the bookmarked files are shown in separate tab-pages.

Code Sniplets

You can remember a piece of code as a so called "Code Sniplet". These sniplets are shared among all workspaces and code-views and are retained in a class variable (they are not lost, when a workspace window is closed). However, they are only persistent inside the image, which means that there is no external file persistency. If you forget to save a snapshot image, or you start ST/X anew, these sniplets are lost . The functions for sniplet handling are found in the "Edit" section in the main menu.

Snipplets can be very easily pasted into a textview via the abbreviation keystroke: type the name of the sniplet followed by CMD-SPACE (on most keyboards, the CMD-key is named "Alt" and found to the left of the space-key).

For example, to paste a template for the "ifTrue:ifFalse:" message, type "itf "CMD-SPACE.

Standard sniplets are setup in "Workspace>>initializeDefaultAbbreviations" as:

AbbrevExpands to
inisNil
nnnotNil
itifTrue: [!]
ififFalse: [!]
itfifTrue: [!] ifFalse: []
intisNil ifTrue: [!]
infisNil ifFalse: [!]
intsisNil ifTrue: [^self]
infsisNil ifFalse: [^self]
wtwhileTrue: [!]
wfwhileFalse: [!]
dodo: [:each | !]
dtdetect: [:each | !]
dedetect: [:each | !]
detdetect: [:each | !]
dtndetect: [:each | !] ifNone: []
clcollect: [:each | !]
cocollect: [:each | !]
colcollect: [:each | !]
slselect: [:each | !]
seselect: [:each | !]
selselect: [:each | !]
rjreject: [:each | !]
rereject: [:each | !]
rejreject: [:each | !]
injinject: ! into:[:pValue :each | ]
exError handle:[ex | !] do:[]
npnextPut:
npanextPutAll:
y yourself.
shself halt.
psprintString
srself subclassResponsibility
stSmalltalk
tsTranscript showCR:
trsTranscript showCR:
ikincludesKey: #
abbWorkspace sniplets inspect
wsDelay waitForSeconds: 1
wfsDelay waitForSeconds: 1
wfmDelay waitForMilliseconds: 1000
slefself
seflself
sself
atiat:! ifAbsent:
iniinitialize
    super initialize.
newinew
    ^ super new initialize.
updupdate:something with:aParameter from:changedObject
    !
    ^ super update:something with:aParameter from:changedObject.
A Array
An Array new>
Aw Array with:>
Aww Array with: with:>
OCOrderedCollection
SCSortedCollection
DDictionary
IDIdentityDictionary
IdIdentityDictionary
OCnOrderedCollection new
SCnSortedCollection new
IDnIdentityDictionary new
DnDictionary new
SnSet new
0(0.0 @ 0.0)
[[: !]
Notice that the position of the text cursor after the sniplet insertion is controlled by the presence and position of an exclamation mark ("!") in the sniplets text.

Also notice, that misspellings such as "sefl" are also included. These help to fix typing errors immediately (as you see them while typing).

Multiple Language Support

Starting with the 6.2 version, workspaces support multiple languages. If the corresponding packages are loaded (libjavascript,libjava, libruby), the evaluation language's syntax can be specified via the "workspace" menu.
Multilanguage support is still being developed, so you might encounter inconveniences. For example, the debugger might not be able to deal with other languages as nicely as with Smalltalk code.

Further Reading

Click here for a tutorial on workspaces, which is found in the "Tutorial for Beginners".
Text edit functions are described in the "Editing Text Section" of the "Getting started Document".
To open a workspace, press this button: .

Inspector - Looking into an Object

Introduction

Inspectors allow looking into an object. They usually consist of 2 subviews, one showing the names (and possibly indices) of the objects instance variables, the other showing the value of the selected instance variable.

There are some specialized inspectors (for example: image inspectors), which add more subviews and/or show the object additionally in a more user friendly form.

Opening an inspector

Inspectors can be started: Beside the obvious behavior, there are some special situations to consider: Examples (click to execute):

    #('one' #two 3.0 4) inspect
 
    #('one' #two 3.0 4) asOrderedCollection inspect
 
    #('one' #two 3.0 4) asOrderedCollection basicInspect
 
    ( #('one' #two 3.0 4) asOrderedCollection removeFirst; yourself ) inspect
 
    ( #('one' #two 3.0 4) asOrderedCollection removeFirst; yourself ) basicInspect
 
    (Image fromFile:'../../goodies/bitmaps/xpmBitmaps/smileys/smiley_angry.xpm') inspect
 
    (Image fromFile:'../../goodies/bitmaps/xpmBitmaps/smileys/smiley_angry.xpm') basicInspect
 
    (Color yellow) inspect
 
    (Color yellow) basicInspect
 
    (Array new:400) inspect

Inspect vs. basicInspect

Sending basicInspect to an object will always open a general inspector, which shows instance variables as they are physically present in the inspected object.

In contrast, inspect is redefined in some classes to open an inspector showing the logical contents. In some collections, the physical implementation uses an extra collection to hold the contents. Try inspecting an (nonempty) instance of Dictionary to see the difference:


    |d|
    d := Dictionary new.
    d at:#foo put:1.
    d at:#bar put:2.
    d inspect.
    d basicInspect.

or the differences in the inspectors of the above examples.

Process Monitor - Show & manipulate Smalltalk Processes

This tool displays a list of active Smalltalk processes (i.e. threads) and their current state. Its popupMenu allows common operations to be applied to a process or a group of processes.
The process monitor is a very useful tool to find (and terminate or debug) leftover background processes - especially during program development & debugging.

[missing fig.: process monitor hardcopy]

To start a process monitor, press this button: .
The fields are: The states shown are: The process which ran at the time of the update is marked with an (*) character. If none is marked, the scheduler was active (or waiting for an event).
Processes which ran during the last timeSlicing period (1/10th second) are marked with a (+) character.

The list is updated every few seconds, so be prepared for some delayed visibility of new processes.

A popup-menu (and tool-buttons in the new version) allows for useful operations to be performed on a selected process:

By holding down the "CTRL" key while pressing the middle button, another popupMenu is opened, which allows toggling the display details flag.
With details on, more info is shown (which you might not be interested in).
The additional information (among others) is: Other items are only of interest for ST/X runtime system debugging.

Probably the most useful item found is the debug function, which opens an inspector-like debugger on the selected process.
This may be useful if some process is waiting on a semaphore and you want to see exactly where the wait is and how it reached it. With the debuggers monitor option, you can even watch & see what that process is doing !

Note:
Since at the time of the view update, the active process is always the process monitor itself, the distinction between run and active states is useless here: you will always see that process as being active in the monitors display.

Semaphore Monitor - Show Semaphores

This tool displays a list of Smalltalk semaphores, their internal count and the list of processes on its waiting list.
This tool is useful to debug deadlock or endless-wait situations in multithread applications.

[missing fig.: semaphore monitor hardcopy]

To start a semaphore monitor, press this button: .
The columns shown are:

Memory Monitor - Displays overall Memory Usage

This utility displays the amount of object memory used by the system, and displays various other statistic values.
Its popUpMenu offers functions to manually perform either blocking- or nonBlocking background garbage collects.
Some of those functions are provided as debugging & measuring tools, and not required by the typical user.

[missing fig.: memory monitor hardcopy]

To start a memory monitor, press this button: .
The numbers shown are (top to bottom):
the other numbers are less of interest to normal users, but give some info to VM developers: the graphic displays a history of the used amount. Newspace size is shown in orange (light grey in b&w displays), freelistspace in green (dark grey) and oldspace in white.

The history is updated twice a second. Use the key-commands 'f' (for faster) and 's' (for slower) to change the update interval.
Pressing 'r' (for reset) rescales the display.

The typical picture shown is some saw-tooth figure; memory use is usually growing until a new-space collection reduces the amount.

The memoryMonitor also provides a popup menu for common garbage collect operations:

The others submenu allows less frequently needed operations to be invoked:

Memory usage - Displays Statistics on Memory Usage by Class

This utility displays the amount of memory allocated by individual classes. The display can be sorted by different criteria - use its popupMenu to change this.

[missing fig.: memory usage view hardcopy]

To start a memory usage monitor, press this button: .

Since scanning the memory is a time consuming operation, there is no automatic update of the list; use the menus update function to manually update the display.

A memoryUsageView is useful to find memory leaks. In Smalltalk, these are not caused by not freeing memory, but instead by keeping references to objects in globals or class variables.
(so, if you find those leaks, don't blame it on the garbage collector; the collector cannot free the memory as long as any reachable reference to an object exists.)
The menu includes two very useful functions, which help in finding those references:

Thus, if you have trouble finding out why some object is not garbage collected, open a memory usage view, select the class and use the ref chains menu function to find out how those instances are still references.

Notice, that the owners function will not be much of a help, if the object in question is kept from being freed by a long chain of references (for example, if it's in a long linked list which is anchored in a global variable).

Also notice, that the ref chains function may be very time consuming.

Object Module Information - Show Loaded DLLs (Class Libraries)

This tool lists the classes/methods/functions as contained in the loaded dlls (shared libraries). This is useful to find out version information in case of an error. The tool's menu also allows for a dll or the complete package to be unloaded.

Its popUpMenu also provides a convenient way to get a module's version information into the clipBoard.

To open a module-info window now, press this button: .

Event Monitor - Displays Events sent to a View

This tool is useful when keyboard mappings are changed or tested. It outputs the incoming event-messages on the standard output (xterm-window / console) or alternatively to the Transcript. (similar to the 'xev' XWindow utility).
To try it, open an EventMonitor, place the mouse pointer into it, and press some key(s) on the keyboard. Watch the trace output.
To start an EventMonitor, press this button: .
An EventMonitor can also be started via the Launchers "System-EventMonitor" menu item.

Graphical View Tree - Shows a View's Widget Hierarchy

This tool displays a view's widget hierarchy graphically (Smalltalk views only). When started via the launcher, a crosshair cursor is shown, and you should click on some (smalltalk-) view on the screen.
That view's widget hierarchy will then be displayed; visible components are displayed in red color, invisible (i.e. hidden or unmapped views) are drawn black.
The popupMenu shows various details about a selected widget and allows further inspection.

[missing fig.: treeview hardcopy]

A graphical viewTree can be opened via the launchers "Tools-Views" pullDown menu; either on a single view (which is to be selected with the mouse), or on all views.

This tool is opened via the Launcher's "Window"-menu. This tool has been obsoleted by the "View Tree Inspector", described below.

View Tree Inspector - Inspect a View's Widget Hierarchy

This tool allows for the hierarchy of a (Smalltalk) window's widgets to be inspected. After startup, you should pick a window by first clicking on the "Pick a Window" button. Then, when the crosshair cursor is shown, click on some (smalltalk-) view on the screen.
That view's widget hierarchy will then be displayed and the menus provide access to various useful information to a programmer.

[missing fig.: treeview hardcopy]

This tool is opened via the Launcher's "Window"-menu.

Method Finder - Find a Selector by Argument & Result

The method finder answers questions of the form: "given this input, and that desired output, what is the name of the method to invoke". A concrete example could be: "what is the name of a function to convert a string from lower- to uppercase".

This tool was ported from squeak, and can be started via the Laucher's "Classes-Special->MethodFinder" menu function.

Use an example to find a method in the system. Type receiver, args, and answer in the top panes, like 4 5 1. Then press the search button. The lower left pane will show all messages which - when send to the receiver 4 with an argument of 5 answer the value 1.

Try it again with a receiver of 'hello', and argument of 3 and an answer of 'llo'.

Finally, to answer the above example-question, try it again with a receiver of 'hello', no argument and an answer of 'HELLO'.

You can write expressions in the fields to create a non-literal object such as a Dictionary (rather than using strings and numbers).
In addition, a limited browser is included: selecting an item in the lower left pane shows the implementors in the upper right pane; selecting any of the implementors will display the methods code in the lower right pane (which is readOnly; i.e. no accept is possible).

The methodFinder-GUI is actually using the MethodFinder-class to do the actual work. This one provides even more search functionality. For example, if you evaluate ("printIt") the following in a workspace

    MethodFinder methodFor: #(
				(4 3) 7
				(0 5) 5
				(5 5) 10)

it will discover (data1 + data2) - i.e. a message selector which satisfies all of the three constraints.

MethodFinder GUI

The MethodFinderWindows provides an easy to use GUI interface to the above described functionality. To use, enter the receiver value, the number of arguments, optionally any argument values, and the expected result (answer) into the top-left panes. Press Search to find the set of methods which conform to this specification.

Some fancy examples of its usefulness are:
Receiver Arg1 Arg2 Result Finds this
'knock knock' $k 'noc noc' 'knock knock' copyWithout: $k
'30 apr 1999' asDate 'friday' '30 apr 1999' asDate weekday
Float pi / 2 1 1.570796 sin

This tools was originally written by Ted Kaehler, Scott Wallace and Dan Ingalls for Squeak.
It is opened via the Launcher's "Classes"-"MethodFinder"-menu,

or by pressing press this button: .

ToDo List - Tool to Remember Things to be Fixed

This tool monitors error and warning-messages from the compiler and displays them in a list. Whenever a change is made to a class or a method, the TODO-list checks if any of those remembered errors is now fixed. If that is the case, the entry is removed from the list. The list is initially empty; however, every compilation error which is confirmed with a "Continue" and many warnings will lead to an entry being added. As an example, try to remove an instance variable which is still accessed in a method from a class.
The use of this tool is especially helpful while programming new code, where some of the sent messages are not yet implemented.
A double click on an entry in the list will open a systembrowser and navigate it to the corresponding code.

Notice: you can quickly check a class (or group of classes) by selecting them in a browser and then performing the "Recompile-All-Methods" menu item in the classLists "Debug" submenu, while a ToDo-List tool is open.

This tool is opened via the Launcher's "Tools"-menu,

or by pressing press this button: .

Breakpoint Browser - Find and Control Breakpoints

This tool shows a list of methods which contain either a static (coded) breakpoint or which have a dynamic trap attached, and makes it very easy to quickly locate and enable or disable breakpoints.

[missing fig.: breakPoint browser hardcopy]

Usage

The Breakpoint-Browser's major use is in finding methods which contain breakpoints and to enable or disable them. When started, the list displays all locations of a breakpoint. For that, the whole system is scanned for breakpoints, which takes a few seconds initially; after that, it watches your changes and updates its list incrementally in real time, without any further noticable delay. Therefore, it is better to keep this view open (or iconified) during a development session, instead of closing and reopening it.
By checking corresponding items in the "View"-menu, this list is filtered by type of breakpoint and by argument.

Breakpoints can be enabled or disabled both by type and parameter. By default, halts and assertions are enabled, whereas breakPoints are disabled.

To open a browser on a selected method, either double-click on the item in the list, or press the "Browse"-button in the toolBar menu. Small editing changes like removing breakpoint code or adding information prints can also be done directly in the code view: simply type it and accept as usual.

Dynamic breakpoints are set/cleared from within the system browser's debugging menu (or via the traffic light buttons). Message selectors for statically coded breakpoints are:

Breakpoints

Of special interest are the #breakPoint: methods; these behave much like ordinary #halt messages, but differ in two aspects:
  1. by default, #breakPoint:-messages are ignored. This means, that you can leave them in production code.
  2. they can be enabled/disabled easily; individual breakpoint groups can be differentiated by their (symbolic) argument.
A typical use of these breakpoints is with the initials of a programmer as (symbolic) argument, to allow individual programmers within a team to control the execution of his own breakpoints. To do so, add a piece of code such as:
    self breakPoint:#ab
or:
    self breakPoint:#ab info:'bla bla'
where #ab stands for an arbitrary key (such as your initials).

By default, these breakpoint-halts are ignored, so that the execution is not interrupted by a debugger. However, they can be enabled or disabled at any time by evaluating:

    self enableBreakPoint:#ab
or:
    self disableBreakPoint:#ab
or from within the Breakpoint-Browser's "Enable"-menu. Typically, this is done by the user named "ab", in order to activate his own breakpoints.

Halts

Halts can also be temporarily ignored by the debugger: the debugger's breakpoint menu includes items to disable a halt for some time, for a number of occurrences or forever. Such temporarily disabled halts can be found quickly by checking one of the halt-filters in the "View"-"Halt"menu. The list's popupMenu also includes a function to re-enable such a disabled halt.

Startup

The breakpoint browser tool is opened via the Launcher's "System"-menu,
or by pressing press this button: .

Notice our convention at Exept Software AG:
in contrast to halts, coded breakpoints can be left in published code as long as further development and enhancements to the code are ongoing or likely, and individual team members are still interested in aspects of the execution. Then, this team member adds a breakpoint with his/her initials as argument to the code, and individually enables all of his/her breakpoints using this tool for testing. As breakpoints are ignored by default, this does not affect other team members.

SUnit - Unit testing framework and TestRunner GUI

This framework (-> Kent Beck, Ward Cunningham and others) allows for convenient component testing.
This tool was ported to ST/X by Samuel Shuster and Travis Griggs - thanks to you and all other Camp Smalltalk guys !

For automatic testing, testcases (subclasses of TestCase) should define a bunch of methods named 'test*', which test various aspects of your code.
For checks, the inherited messages #assert:, #should, #shouldNot etc. should be used.
See the provided ExampleSetTest for more info on how to use this.

The TestRunner GUI interface automatically searches for all testCases as present in the system, and offers execution via a convenient pull-down list:

[missing fig.: sunit testRunner hardcopy]

After selection of the test, run its test-methods by pressing the Run-Button.
All failures will be collected and provided in the lower pull-down list for debugging.

Although simple, this is a very useful tool and we highly recommend its use - it will make your life MUCH easier. Please read some good book(s) on eXtreme programming or Kent Becks original "Smalltalk Testing"" paper for more information.

Using the TestRunner

The TestRunner is started either by double-clicking on a TestCase class in the browser, by evaluating:
    TestRunner open.
or via the launchers "Tools-SUnit" menu item.

A test runner can also be started with this button: .
The main information window displays progress information (while executing testCases) and the final result. Its color is changed to yellow while executing, and back to green (if all ok) or red if any testCase failed.

Notice that some of the test runner's functionality has also been built into the New Systembrowser.

This tool can also be opened via the Launcher's "Tools"-menu.

Version Diff Browser - Compare two Versions of a Class

This tool provides a side-by-side comparison for two versions of a class or two classes. Typically it is used to compare the current (in-memory) version of a class against an other version of the same class in the source code repository.

Packager - A Standalone-Executable Builder and Packager

This assistant-application allows for standalone applications and binary class libraries to be built very easily. It will generate all required classes, files, start the compilation process, generate a self-installing executable with a few mouse clicks. A simple demo application like the (in)famous "Hello World" can be generated in a few minutes (read the Introductionary Text for more info about it).

Prerequisites

Windows Users:

Please install either the "Borland Free Commandline Compiler Tools (bcc32)" or the "Microsoft Visual-C++" package (also free). In addition, the "NullSoft NSIS-Installer Package" is required.

Due to limitations and bugs in the Visual-C++ compiler (limit on the size of string-constants), some Smalltalk code is still not compilable (classes which contain image-resource methods for big images). Although microsoft is doing their best (a relative measure) to make things better (they increase the string-limit with every new release), they still seem to be undable to figure out how ti use malloc for string-data). We are patiently waiting for a real fix and still using bcc in the meanwhile. Therefore, we still recommend using the borland compiler suite. Please install it at its standard location ("C:\Borland") as our makefiles might still contain hard-coded pathes (yes, we are ashamed about this).

Unix Users:

You should already have the gcc compile suite (including all required header files) installed and ready to use. For a lack of time on our side, there is currently no self-installer support for Unix. The packager will generate a zipped tar file, which must be deployed and unpacked for use. This may change in the near future.

Packages, Projects, PackageIDs and ProjectDefinitions

Smalltalk/X basically uses two objects for packaging and package identification: Older ST/X versions used instances of a Project class - this is now obsolete and will be removed from the system (although there are still some minor uses of it, which might remain there for backward compatibility for some time, as some customers have built their own packaging scheme around it).

PackageIDs

These are simple symbols and are attached to classes and methods. If a method has a packageID different from its class, it is called an extension method.
PackageIDs are used by the source-code manager to locate a classes' source container within the directory hierarchy. Therefore, these IDs must have a certain fixed format: they always consist of exactly two parts, the module and the directory part, which are separated by a colon character. The module is used as main-selector on where and how the source code repository is accessed. The directory is a path below that repository. If checked out into the local filesystem, the module defines the top-level directory. Thus, if a packageID is "stx:libbasic", the corresponding sources will be found in the repository associated to the "stx" module, under the directory "libbasic". In the local file system, it will be found under "stx/libbasic". As another example, if the packageID is "exept:expecco/plugins/foo", the repository is whichever is associated with the "exept" module, and the subdirectory is "expecco/plugins/foo". The local path to the sourcefiles would be "exept/expecco/plugins/foo".
Please notice that it does make sense to associate different repositories to different modules: for example, you could setup the sourceCodeManager to use CVS access to the exept repository for everything under the "stx" module, and at the same time, use a local SVN repository for everything under the "myCompany" module.

Your own projects should always have a module which is distinct from other people's modules (and especially from "exept" and "stx"). A good choice is your company name, your name or a similar. This avoids conflicts, when you load other's packages later.

ProjectDefinitions

These describe the contents of a project, such as the classes to include, the set of extension methods, any additional compilation information. ProjectDefinitions come in 3 flavours: ProjectDefinitions are stored and managed as class-instances, located as subclasses of one of ApplicationDefinition or LibraryDefinition. As classes, they are themself managed, compiled and packaged as part of the project (and also have the same PackageID as their components). They are also treated like any other class w.r.t. source code management.

Packaging

All classes and extension methods belonging to a single package are supposed to be loaded (and possibly unloaded) together. They are also usually deployed inside a single dynamic link library ("dll", for short). In the Unix world, these are called "shared object" or "so". Finally, they are stored in a common directory both on the local file system and in a source code repository (CVS, SVN, etc.).

Structure of a Project

The artefacts as manipulated by the packager are:

Build Procedure

All of the three components above can be generated for you by the packager, to provide an initial framework for further work. Of course, this automatically generated code will only implement an empty application without any useful functionality. However, it is easy to modify this into something more interesting, using the UI-Painter, the Menu-Builder and the SystemBrowser.

When these classes have been defined, all required files are stored in a temporary build directory. This means that the classes are filed out, and make- and other support files are generated.

Finally, the actual build process is started. This requires an external C-compiler. Under windows, both Borland-C (free download available via the internet) and Microsoft's Visual-C++ (also available for free) can be used. Support for the lcc compiler suite is also being developed, but not yet finished. As of Nov 2009, we still recommend the use of the Borland Suite (bcc), because the Microsoft compiler still has serious bugs which prevent some classes from being compiled (especially: the string.constant limitation is fatal).

A self-installing executable is built using the NullSoft NSIS package. This is also required to be installed before the packager is started.

After the build, all required files are packaged in a single install-file. This is called "MyApplicationSetup.exe" and found in the project-specific subdirectory of the build directory. For deployment, this single file has to be delivered to a customer and executed there.

Summary: It has NEVER been easier to create a GUI application.

Terminal - A Shell Terminal

This application provides a VT100 terminal emulation as an interface to the Operating Systems command line interface (i.e. "shell" under Unix / "command.com" under DOS based systems).

This application is known to have some bugs:


[stx logo] Copyright © 1995 Claus Gittinger Development & Consulting, all rights reserved

<cg@exept.de>

Doc $Revision: 1.139 $ $Date: 2012/06/01 11:25:05 $