1084-1084

Previous Table of Contents Next

Page 1084

One of the more interesting features of the SQLWindows model of inheritance is the concept of class variables. SAL distinguishes these from instance variables , which are treated as normal class members . No matter how many instances of an object are created, they share the same class variables. In other words, class variables are global to the class. This implementation can be somewhat useful. For example, a database connection class could have a global counter that stores the number of active connections. Unfortunately, this counter would be somewhat tedious to maintain because, for non-visual classes, constructors and destructors do not exist. The code that creates a new instance of a non-visual object is responsible for calling member functions used to initialize the instance. By the same token, the code that destroys a non-visual object is responsible for calling any clean-up routines.

In fact, the concept of constructors and destructors is not really a part of visual objects either. Visual objects simply have the capability to respond to the Windows messages WM_CREATE and WM_DESTROY, which are represented by SAL as SAM_Create and SAM_Destroy. By defining Message Actions to respond to these messages, the rough equivalents of constructors and destructors can be created.

Another feature of SAL that seems somewhat at odds with the object-oriented model is the fact that all data members and member functions are public (except for variables declared within functions). It would also seem that the programmer should be able to declare variables within Message Actions, which are the closest thing to private member functions within SAL. The fact that variables cannot be defined in event-handlers should be kept in mind when designing SQLWindows applications, so you can attempt to keep the number of instance variables (or window variables) to a reasonable level.

Despite a few shortcomings in the object model employed by SQLWindows, the SAL programming language has many powerful features. Perhaps the most useful of these is the capability to create and respond to user-defined messages. A message can be defined as a global constant in the User section and sent to forms and controls using the SALSendMessage() function. To respond to a user -defined message, a window or control need only add the message and code to handle the message in its Message Actions section. The way in which event handlers are defined in SAL maps into the actual Windows message very well, which allows SQLWindows objects more flexibility in the messages it can respond to.

SAL also has very good support for common Windows APIs, including DDE, OLE, and (through QuickObjects) MAPI. You can also use QuickObjects to interface with Lotus Notes and NetWare mail, making it very easy to build messaging capabilities into SQLWindows applications. The outline editor and a few unorthodox features of SAL take some getting used to, but overall, SQLWindows is a serious client/server development tool. It is particularly well-suited to rapid prototyping, through the use of QuickObjects.

Previous Table of Contents Next