AtOne Features

• AtOne is open source and free

• Full support for Unicode strings. Within all the code in AtOne any references to null terminated strings or characters within strings are handled in a Unicode/Multi-Byte Character Set independent manner. This is handled by the use of macros that define the types for characters and character strings. A pointer to a string is macro defined as string whilst a character within a string is macro defined as character. To construct applications that are compilable as Unicode and MCBS we encourage the exclusive use of these macro defined types as well as the AtOne string class OsiString.

• Context sensitive help supported on windows and menus with Tooltips supported on windows. Tooltip text and context sensitive help id are attributes of the base window class and handle these features automatically. F1 menu help is provided automatically through an association table of menu Id's with corresponding help Id's. Furthermore, all windows support context menus (right mouse button) through a property containging the popup menu.

• Unified window life-cycle management, reference counting and class identity is provided on all window classes. This approach provides unprecedented flexibility in the creation of management code behind graphical user interfaces, freeing programmers of unecessary programming head-aches that arise out of creation order and pointer management issues.

• Extensive GDI support - MFC provides a thin wrapper over GDI that makes graphics programming in MFC little different from native WIN32. Although WIN32 is a fairly extensive and flexible graphical API it is not easy to code. MFC does little to simplify the process. AtOne, on the other hand, has entensive GDI support in classes designed to relieve you from the unecessary complexities of WIN32 GDI. Graphical drawing objects such as fonts, pens, brushes and regions are handled in a unified manner. An extensive collection of graphical primatives such as Lines, Polylines, Rectangles, Polygons, Text etc. are provided in an object form. This approach allows graphics to be constructed as a collection of objects rather than a series of GDI operations. AtOne also provides complete palette support (a feature commonly avoided in other frameworks) as well as full GDI printing support. 

• Extensive message hooking mechanisms are provided in the base window class. The inclusion of a transparent message hooking mechanisms independent of WIN32 API has allowed AtOne to do away with the conventional message loop typically found in WIN32 applications. More specifically, the provision of this mechanism has allowed the message loop in AtOne to be free of calls to ::IsDialogMessage() and the like, simplifying the message loop and removing any unecessary coupling with other framework objects such as dialog boxes.

• Dialog box instantiating provided through the direct reading of dialog resources embedded in the application. The approach of reading and processing the dialog resource directly rather than relying on the WIN32 Dialog functions is different from most other frameworks. You could well ask why do it? The answer multi-facetted. Firstly, the use of WIN32 Dialog functions to create a dialog will, of necessity, create a new type of window object (called a dialog) because they are created in different ways. However, at the WIN32 level there is little difference in a dialog and a window. Therefore to mimmic this in the framework may require a great deal of unecessary duplication of functionality between a Window class and a Dialog class. More importantly, the traditional approach gives rise to two classes that are apparently both window classes but which have markedly different behaviour and constraints on there use. In reality this difference is a purely contrived one as a dialog script merely defines the location and type of windows to be created on a window of given class. Possibly the most important issue though, is the ability to create and use a resource script that uses a custom control written in the application framework. Typically this has been handled in other frameworks by forcing developers to derive their control from a predefined WIN32 control class and super-classing from that class. The resource script then defines the control using the WIN32 control class and a call to the "dialog type" constructor of the control is used. This then necessitates two ways of creating a window. One when the wrapper class creates the window and another where it merely super-classes a control created by the dialog instantiation. This introduces a great deal of complexity in the base window class as it now becomes necessary to track how the control was created and act accordingly. By actually reading and processing the resource script directly, AtOne avoids all these complications since the controls and windows are all created in exactly the same manner (no modes) and a completely new control class (that is not sub-classed from an exisiting WIN32 windows class) can be designed and used in a dialog box without any special coding. This brings unprecedented flexibility to coding new controls for use in the AtOne application framework. 

• Built in application state management. One of the most complex issues in programming development is in managing the state of an application. In this case, by state we mean the state of menus and windows (enabled, disabled, checked etc). Traditionally this has been handled by having event handlers that individually change the state of menu items etc. based upon a given transition. The problem with this approach is that the code that then manages the application state is distributed throughout the whole application. As the application becomes larger the more complex the state management code becomes, making it increasingly difficult to correctly design and maintain the code that handles the application state transitions. AtOne approaches this problem from a completely different perspective. In AtOne the developer defines a set of state transitions corresponding to certain program events and adds these transitions to a state manager. The transitions can then be invoked by the state manager when the appopriate event occurs. The state manager also has internal state variables which can be used in state transition pre-conditions to ensure that a given transition can only occur when the pre-conditions are satisfied. This approach dramatically simplifies the coding and maintenance of application state management code. 

• Built in geometry layout management. Another complex issue within GUI programming is having the ability to manage the layout of a collection of windows within an application. Tradtionally WIN32 based application frameworks such as MFC and Object Window provided no support for automatic layout management, leaving the developer to develop their own (either as a generic layout management scheme or one specific for a particular application). AtOne provides geometric layout management as a native part of the framework. An extensive layout manager has been supplied that should suffice in most cases. However, should the range of functionality prove inadequate it can be easily replaced by a more flexible layout manager. In future the layout manager shall under-go some extensive changes to provide the most flexible layout management possible.

• A range of macro defined template classes are provided with AtOne, including Linked Lists, Hash Tables, Stacks, Queues and multi-cast callbacks. Macro defined templates were used to minimize the size of the code base. You could well argue that it would have been better to make use of STL rather than re-invent the wheel. In theory that is certainly a valid point however, since STL is an immature library specification there is a wide variability of performance in the STL libraries provided by various compiler vendors. By only using internally developed template classes the performance of AtOne is identical irrespective of the compiler used. This ensures that all bugs within AtOne are traceable to the AtOne library and not just a manifestation of a particular implementation of STL. You are, however, free to use STL for your own coding should you wish to.

• A wealth of other low level support classes are provided to simplify common or complex programming tasks. 

Paavo Jumppanen
Creator of AtOne Application Framework