System Requirements

The following system configuration is required to run DatabasePak and Database Xcessory version 1.5:

At least 16 MB of RAM (we recommend 32 MB of RAM)
The amount of disk space listed in the following table (according to your platform):

Platform	Database Xcessory (with one database)	Each Additional Database
HP 9000/700 (9.x)	57 MB	19 MB
HP 9000/700 (10.10 and above)	65 MB	50 MB
IBM RS6000 (4.2)	53 MB	13 MB
DEC AXP OSF/1 (3.x and above)	70 MB	30 MB
SGI (IRIX 5.3 and above)	69 MB	21MB
Sun 4 (SunOS 4.1.x)	69 MB	26 MB
Solaris 2 (SunOS5.x)	61 MB	24 MB

X11R5 or higher
OSF/Motif Version 1.1.x or 1.2.x, DEC/Motif 1.2.x, or CDE Motif

Note: If you plan to customize Database Xcessory with user-defined widgets, callbacks, and editors, you must run version 1.2.x.

High resolution graphics display: 1024 x 768 is required;
1280 x 1024 is recommended
C compiler or C++ compiler supplied by your hardware vendor
(g++ is not supported)

Software Version Information

DatabasePak and Database Xcessory use the following software versions:

X Window System Version 11 Release 5
OSF/Motif 1.2.x
FLEXlm 3.0 License Manager

Documentation

The DatabasePak and Database Xcessory documentation set includes the following ICS manuals:

DatabasePak and Database Xcessory User's and Reference Guide
DatabasePak and Database Xcessory Release Notes (this document)
DatabasePak and Database Xcessory Installation Notes
DatabasePak and Database Xcessory CD-ROM Mounting Instructions
Builder Xcessory User's Guide
Builder Xcessory Reference Manual
Builder Xcessory Release Notes
EnhancementPak Programmer's Reference
EnhancementPak Release Notes
GraphPak Programmer's Reference
ViewKit ObjectPak Programmer's Guide
ViewKit Release Notes

New Features

The following sections describe changes and additions to DatabasePak and Database Xcessory since version 1.0.2.

Informix Support

Database Xcessory now supports Informix 7.2, and includes a new widget, XiDBInformixDataSource. Refer to "Informix Issues" for more detailed information.

KL XRT/Table Integration

Database Xcessory 1.5 includes integration with the KL XRT/Table widget. The XRT/Table widget provides more functionality than the XiDBTable widget.

Extended List

The XiExtended18List widget from EnhancementPak is provided in a data-enabled form. The two variations of the widget are as follows:

XiDBExtendedList--an Enumerated Data Presentation implementation of the XiExtended18List widget.
XiDBExtendedListQuery--a Query implementation of the XiExtended18List widget.

Improved QBE Interaction

All Data Presentation widgets have new resources that allow more advanced Query By Example (QBE) customization. XmNqbeStyle controls the behavior of the field when entering QBE mode. XmNqbeOperator specifies the SQL operator (for example, LIKE, EQ, etc.) used for the field. XmNqbeValueString specifies the default value for the field when entering QBE mode.

XmNselectOnFocus

A new resource added to the XiDBDataField widget that causes the contents of the widget to be selected when the widget gains focus.

XmNstorageValueString

A new resource added to all Data Presentation widgets that specifies an expression used to fill this field when the record is written to the database via an update or an insert. For example, for a field that stored the timestamp of the last change to the record, you can set XmNstorageValueString to "getdat()" (in Sybase) to store the current date/time when the record is updated.

XmNautomaticBeginQuery

A new resource added to all Query and Enumerated widgets. When an "@value()" function in the XmNwhere resource of a Query (Q1) refers to a widget associated with a different Query (Q2), Q1 is considered dependent on Q2. When XmNautomaticBeginQuery is True (when Q2 moves to a different row in its result set), Q1 automatically requeries the database, because the contents of its where clause have changed. This was the default behavior in DatabasePak 1.0. When XmNautomaticBeginQuery is False, Q1 does not automatically requery, and you must initiate the query when appropriate.

New Functions: @user, @osuser, and @osuid

For use in expressions such as XmNwhere and XmNdefault; @user evaluates to the current database user name, @osuser evaluates to the current operating system user name, and @osuid evaluates to the current operating system user ID.

XiDBApplicationModifiedDatabase()

A new function that notifies DatabasePak that the application made changes to the database (probably with XiDBDoProcedure or XiDBDoSQL) that are not yet committed. This causes DatabasePak to issue a "COMMIT WORK" statement the next time you instruct DatabasePak to commit. If this function is not called, and DatabasePak has not issued any insert, update, or delete statements, the "COMMIT WORK" statement is not sent.

XiDBQuerySetField()

A new function that allows you to set the value of a field in any row in a rowset.

Integration with Builder Xcessory 4.0

Database Xcessory 1.5 is integrated with Builder Xcessory 4.0. All Builder Xcessory 4.0 features are available to Database Xcessory users, with the exception of Java code generation.

Standardized Installation

DatabasePak and Database Xcessory 1.5 uses the ICS Installation manager used with all other ICS products.

DatabasePak and Database Xcessory Examples

Several examples, including source code, are available here.

Source code for the examples listed in the DatabasePak and Database Xcessory User's and Reference Guide is on the distribution CD-ROM:

{DXHOME}/examples/tutorials

Bug Fixes

For a list of all bugs fixed for this release, read the file located in the following directory, where {Database Xcessory} is the installation directory of DatabasePak and Database Xcessory:

{Database Xcessory}/admin/FIXEDBUGS.

Release Limitations

Sun Platform Limitations

The following sections describe known limitations of the DatabasePak and Database Xcessory 1.5 distribution on Sun platforms.

Link Error on Solaris 1 with Sun C++ Version 4

If you are using SparcWorks 3 (and the Sun C++ compiler version 4) on SunOS 4.1.3 systems (Solaris 1), you might experience a link error when compiling DatabasePak code. Several symbols internal to the C++ library (specifically _scd_register, _scd_deregister, _ex_table_count, _ex_table_head) are not resolved properly when -lC is dynamically linked. Sun produces a "C++ Jumbo Patch" for this compiler, that might help. You can avoid the link error by changing "-lC" to "-Bstatic -lC -Bdynamic " in your makefile.

CDE/Motif Patches for Solaris 2

The XiDBList widget exercises a bug in early patch levels of Solaris CDE/Motif. If you experience a "hang" when creating an XiDBList widget in either Database Xcessory or your compiled application, you must obtain the latest Motif patch from SunSoft at

http://access1.sun.com/patch.recommended/rec.html

Version Incompatibility with dbx Debugger on Sun Systems

On Sun SPARC SunOS 4.1.x systems, you can use the dbx debugger to debug your DatabasePak-based application (if you have added application code). However, be sure to use the dbx debugger from the Sun SparcWorks distribution rather than the older version installed in the system area. For reasons yet to be determined, the older version does not work properly with the symbols in DatabasePak, and dbx exits without permitting you to debug the application.

Known Problems

The following sections describe known limitations of the DatabasePak and Database Xcessory 1.5 distribution.

Reading Previously Created UIL Files

When Database Xcessory 1.5 / Builder Xcessory 4.0 reads in UIL files created with earlier versions of Database Xcessory/Builder Xcessory, the following three items of information can get lost:

Application Name
Application Class
Application Defaults File Name

The older UIL files identify these items as follows:

!(BX) bx_info("app_class", "MyApp") 
!(BX) bx_info("app_name", "myApp") 
!(BX) bx_info("app_defaults", "MyApp.ad")

The current UIL files identify these items with the words LANG_{name,class,app_defaults}, where LANG is the specified language for this application (c, c++, or vk). For example, using the C language, lines appear in a UIL file created by Database Xcessory 1.5 or Builder Xcessory 4.0 as follows:

!(BX) bx_info("c_name", "BuilderProduct") 
!(BX) bx_info("c_class", "BuilderProduct") 
!(BX) bx_info("c_app_defaults", "app-defaults", true)

To change the application information back to the desired values, select Language Settings from the Options menu of the Browser, and change the relevant entries on the File Names and Code Generation tabs.

Play Mode in Database Xcessory

Usually, Database Xcessory Play Mode rolls back any changes you make to the database. However, Database Xcessory cannot do this with Informix databases created without the 'with log' option. When you enter Play Mode while connected to a database that cannot support transactions, you get a warning in the Database Xcessory Browser message window. Then any modifications made while in Play Mode will be permanent.

Use of UIL Code with Classes Problematic

You can create user-defined classes with Database Xcessory and generate the code into UIL, which the tool can re-read. However, attempting to compile the UIL and run the resultant binary may fail. Because the class name becomes part of the widget name when widgets are constructed for UIL, resources that are widget references might not be resolved correctly.

Using UIL Code with Widget References Problematic

You can create an interface with Database Xcessory and generate the code into UIL, which can be compiled by the UIL compiler. However, it has not been confirmed that the Motif Resource Manager library (used at run-time to interpret the output of the UIL compiler) correctly resolves resources that are widget references.

XmNfrom Resource Value

In Database Xcessory 1.5, the XmNfrom resource always has a value. If you set XmNfrom to an empty value, the previous value is restored.

Notes for All Platforms

User-defined Editor Function Prototypes

The function prototypes for the EditorCreateFunc functions dotCreate and rscCreate and the EditorUpdateFunc functions dotUpdate, dotFetch, rscUpdate, and rscFetch have changed since Builder Xcessory 2.x. If you used previous versions of Builder Xcessory to add user-defined editors, change your customize.c file to reflect the new parameters. This requirement only applies to users who have customized their builders by adding editors to Builder Xcessory. For more information, refer to the Builder Xcessory User's Guide.

Inclusion of White Space and Special Characters

A quoting mechanism in the XmNmap string specification allows explicit inclusion of white space and other special characters. The backslash character "\" tells the parser to automatically include the subsequent character as part of the map specification.

Compiler Issues

Although you can use DatabasePak with a C compiler, the DatabasePak library internally includes C++ code. Vendors of C++ compilers have not established a standard for the linking mechanisms for C++-based libraries. Therefore, the libDBPak.a in your DatabasePak distribution is specific not only to a platform, but also to the particular C++ compiler used on that platform.

This is also true for the Database Xcessory object file. If you relink the object file with your own widgets to produce a new Database Xcessory binary, you must use that particular C++ compiler to avoid unresolved symbols.

Focus Model

Because Database Xcessory uses many windows, we suggest that you use a "follow-pointer" focus model (Mwm*focusPolicy: pointer) instead of a "click-to-focus" model (Mwm*focusPolicy: explicit). The latter might cause inconvenient raising of windows. Database Xcessory operates correctly in both modes.

Placement Grid

The placement grid is not visible, though you can change its configuration as noted in the documentation.

Requests for License Keys

Send any requests for license keys to keys@ics.com.

Resources of Type Integer

After you set a widget resource to an integer value, the value will change back to its original value under the following circumstances:

Xt Geometry management

Often a temporary problem caused by denied geometry requests. For example, a widget tries to resize because of a new borderWidth, but its parent does not allow it to resize. You cannot change borderWidth. The easiest solution is to make sure that all the ancestors of a widget allow their children to resize.

Subclassing within Motif Toolkit

Access to, or validity of, a resource depends on the widget's parent. This often happens with widgets that are subclasses of XmLabel. When they are children of XmPulldownMenus, the menu overrides (either at creation or during SetValues) some of the widget's resources and you are unable to change them. You must check the source code to determine when this will happen.

Shrinking Panner

On very large interfaces, the Browser panner can disappear because the size of the panner reflects the percentage of the interface seen in the Browser. Resizing the Browser or the panner canvas can make the panner visible again. Alternatively, you can simply click MB1 inside the panner canvas and drag the pointer. This moves the visible portion of the interface hierarchy inside the porthole. You can also traverse to the panner and use the arrow keys to pan.

XIO Errors

Resizing the Browser message window so that it is completely obscured or takes up the entire Browser window results in an XIO Error, and prints a message in the message window. This XIO Error does not affect Database Xcessory, and does not affect the current interface. You can ignore the error.

Online Help

If online help does not start correctly (usually when a previous invocation did not clean up shared resources properly), inspect the properties on the root window by entering the following at the command line:

% xprop -root

If HyperHelpAtomV40 is included in the displayed list, enter the following at the command line:

% xprop -root -remove HyperHelpAtomV40

You should now be able to start up the online help from Database Xcessory.

CodeCenter and ObjectCenter

Version Support

Database Xcessory supports CodeCenter 4.x and ObjectCenter 2.x for Solaris 1.x, Solaris 2.x, and HP-UX 9.0.x.

clms_registry

CodeCenter version 4.x (ObjectCenter 2.x) includes the communication server clms_registry, which should be installed during the normal CodeCenter installation. This program must be running in order for Database Xcessory and CodeCenter to communicate.

Reading Builder Xcessory 2.x Interfaces

Database Xcessory 1.5 encloses in parentheses any callback parameters or widget storage strings read from interfaces created with versions of Builder Xcessory prior to version 3.0.

To disable this behavior, append the following line to your .bxrc file:

*defineConversion: False

Code Generation

Overview

Code generator

The standalone code generator is called cgx in {DX}/bin. You can run the code generator from the command line, but it requires a Database Xcessory license to run. To determine the exact syntax, use the cgx -help command. The most common syntax is the following:

% cgx -file foo.uil -path {DX} -generate {LANG}

{DX} is the Database Xcessory system directory (usually /usr/lib/X11/dx15).

`{LANG}`

{LANG} is one of the following:

C (for C language generation)
CXX (for C++ language generation)
App (for App defaults generation)
C_UIL (for UIL/C generation)
VK (for ViewKit/C++)

Switches

The cgx -help command displays the available switches for the cgx command. The following switch is also available:

-directory	 Sets the directory in which the code is generated.

You must always specify -path, even with -help.

Language Specific Issues

C (C Language Generation)

C language generation is fully compatible with previous versions of Builder Xcessory. Additionally:

Database Xcessory generates SET routines for exposed class resources.
Timer procedures and work procedures are output in the callbacks file.
Event handlers are output in the callbacks file.
User code can be placed between designated code blocks in the main-c file.
Files that have not changed are not regenerated.

CXX (C++ Language Generation)

Database Xcessory inserts special comments in the output code for the main file and all base files. If you put your code between these comments, Database Xcessory retains it from code generation to code generation. Other improvements include the following:

Database Xcessory generates SET routines for exposed class resources.
Shell(only) callbacks and event handlers, timer procedures and work procedures are output to a callback file (like) C.
You can put user code between designated code blocks in all base class files and the main-C file.
You can turn on derived class generation from the C++ Output File Names Dialog for interfaces developed in previous versions of Builder Xcessory. The new default is to have derived class generation turned off.
Files that have not changed are not regenerated.

C_UIL (UIL/C generation)

UIL/C generation should be fully compatible with previous versions of Builder Xcessory. Additionally:

Timer procs and work procs are output to the callbacks file.
Event handlers are output to the callbacks file.
Place user code between designated code blocks in the main-uil file.
Using App placement for exposed class resources is not supported.

Generating ViewKit Code

With Database Xcessory 1.5, you can generate ViewKit code. ViewKit is a class library available from ICS as ViewKit ObjectPak or from SGI as IRIS ViewKit. ViewKit provides an application framework for developing applications in C++ and Motif. Generating ViewKit code from Database Xcessory provides an application completely derived from ViewKit classes.

VkComponent class

The most basic of the ViewKit classes is the VkComponent. All classes defined in your application are derived from VKComponent (similar to the UIComponent used in C++ code generation). VkComponent defines the basic structure of and programmer's interface to all ViewKit components.

VkApp class

Your application is controlled by the VkApp class, which handles initialization, event processing, and window display control. The VkApp class is created in the main file of your program.

In addition, all top level shells in your applications are made into subclasses of the VkSimpleWindow class. The name of this class is the name of the top level shell widget. (We recommend that you rename these widgets with more recognizable names than the Database Xcessory default names topLevelShell1, topLevelShell2, and so forth.) The VkSimpleWindow provides simple interfaces to raise, lower, and iconify your window as well as communication with the window manager.

Because code in Database Xcessory 1.5 is generated from TCL template files, we can easily provide updates to the ViewKit code generation. New editions of the ViewKit code generator are available here.

Makefile Generation

Database Xcessory generates Makefiles using a scheme that does not depend on static information stored in your ~/.bxrc or ~/.dxrc files, in Database Xcessory resources, or in the UIL file. To pick up the references to the new libraries, remove references to the following resources in the ~/.bxrc and ~/.dxrc file:

*cMakefileLibraries:
*uilMakefileLibraries:
*cppMakefileLibraries:

In addition, when editing existing UIL, change the values on the Makefile tab of the Browser (see Builder Xcessory 4.0 Reference Manual, Chapter 3) so that the older values are not carried along into new projects that you create.

Customizing Makefile Generation in Database Xcessory

Database Xcessory automatically generates Makefiles and/or Imakefiles. Usually, the Makefiles will be correct, but if your site does not have all required software installed in standard locations, you might want to customize certain files in the Database Xcessory system directory to create perfect Makefiles every time.

Documentation Type:

Database Xcessory

Search form