|Last updated April, 21st 1998.
Back to OPaC official page.
Current version : 1.0.1, information on previous
versions can be found here.
Release date : April, 21st 1998
- The <OPStorage> and <OPCarbonCopy> classes have
been modified in order to handle properly automatic type conversions (e.g. from
<OPValue> to another type and vice-versa).
- A new <OPaC_TypeInfo> internal class has been added in
order to collect and publish information about the basic OPaC data types. This data is
made available through the new <OPTypeInfo> class.
- A new <OPBitsetInfo> class has been added to represent
- The base class <GetPublicData> methods have been
changed to return the type information as instances of <OPTypeInfo>. This provides a
simpler and more coherent interface (also modified for class <OPDataMirror>).
- The <OP_TARGET_ARG> macro has been expanded and a
third argument is now required. It is used as a description of the argument.
- The <DELETE_ARRAY> and <DELETE_ARRAY_FROM_ZONE>
macros correctly free the memory, even with compilers which allocate an additional counter
at the beginning of an array (the counter is used by <operator delete>). Beware
to use these macros only with structs/classes which have a <vtbl> (because of a
virtual member, embedded object, etc.) !
- The <OPList> and <OPHashTable> classes have been
extended. Class <OPList> now supports a rudimentary cache.
- The format of the archives has been slightly modified: the
archive files now have a 32-byte header containing an archive identifier, represented by
the string "OPaC-BIN" followed by 8 zeroes and the text "binary
archive" padded with 2 zeroes.
- The <OPStorage> class treats objects tagged with
"AutomaticObject" in a special way (the attribute must be a dictionnary); the
dictionary is stored in place of the object. When restoring, the dictionary's contents
will be interpreted as following: "Type"=="Type:Path",
"Root"=>root and "Path"=>path used to retrieve the object thanks
to OPQueryData with the specified root and path.
- The <operator ->> of <OPObjectRef> (and all
other references) now calls the <CheckAndResolve> method, so that the object gets an
opportunity to replace the <OPObjectRef> pointer by another object's (useful for the
- The methods <Resolve> and <CheckAndResolve> have
been added to the base reference class and to the base class too.
- The storage class now supports internal purging when storing
- The missing class <OPDictIterator> has been added.
- A new class <OPDicTree> can be used to represent
arborescent dictionary like structures (kind of registry).
- The look manager now reads its defaults from an
initialisation file (a kind of "policy" file or registry).
- The class <OPObjectWell> has been extended and
provides a "new" button. Furthermore, it always accepts dropping.
- The class <OPWindow> has been extended in order to
handle modal dialogs and windows.
- The class <OPTabView> has been reparented. The parent
class <OPMultiView> provides some of the functions formerly implemented in
- A new class <OPStepView> has been added, so that
step-by-step wizards can easily be implemented.
- The class <OPDragView> supports the
"EmbeddedObjectForDrag" attribute on its view, so that abstract objects can be
dragged and dropped in a more user friendly way.
- Buttons support translucid background colors.
- The IB uses dynamic message passing to find out if an object
has to be initialised further after cloning.
- The IB provides an improved "New" function for the
views, which allows dynamic instanciation and initialisation of complex widgets, based on
a step-by-step wizard
Systen Dependent (Win32 & Linux)
- The complete graphical abstraction layer has been
reimplemented based on the "grafix" library in order to support alpha
transparency and translucency.
- The font engine relies on the FreeType implementation.
- The color manager is now 100% system independent (since an
internal true color model is supposed).
- The Font Manager is now system independent. The only
parameters which are needed for its initialisation are directory paths and file names.
This is not yet fully implemented.
- The current implementation of sd_grailwdo.cxx is
very slow. It is based only on the <XDrawPoint> primitive, which is unacceptable for
raster-ops. This will have to be implemented more seriously soon.
- Documentation about porting is now included in the source
distribution. It may be somewhat out of date with respect to the graphic engine.