************************************* * * * DB/C Newsletter * * October 1998 * * * ************************************* News and Comments This month's article is a continuation of the discussion of JavaBeans and DB/C JX. The article discusses how to control JavaBeans from your DB/C program. Beware that the information in this article is preliminary; it may change during beta testing. Sun (Javasoft) continues to refine Java release 1.2. As of the end of October, the most recent test release of the Java Developer Kit (JDK) 1.2 is called JDK 1.2 Release Candidate 1. Several significant changes have been made in this version of the software. All of the GUI features of DB/C JX 2.0 depend on JDK 1.2 features. We have therefore delayed beta testing of DB/C JX 2.0 until we're confident that the combined quality of JDK 1.2 (release ?) and DB/C JX 2.0 (beta release 1) is high enough to start customer testing. Interest in DB/C FS continues to be quite high. Many requests have been made for additional features. We are attempting to prioritize these requests and respond to them in a timely manner. We appreciate the patience of those of you who are waiting for specific capabilities to become available. don.wills@swc.com ***************************************************************************** GUI JavaBeans in DB/C JX 2.0 As discussed in the previous article, some JavaBeans are visual elements in a GUI environment and other JavaBeans that are not GUI elements. The JavaBeans support described in this article is limited to those JavaBeans that are GUI elements. The article in the April 1998 DB/C Newsletter describes an an interface for calling arbitrary Java classes from DB/C JX programs. This code can be adapted to interface with non-GUI JavaBeans. DB/C JX 2.0 will contain support for GUI programming. This support is virtually identical to the GUI programming support in DB/C 9. An overview of the DB/C 9 GUI capabilities is found in Chapter 3 of the DB/C 9.0 Programmer's Reference. You should be familiar with the information in that chapter to understand the following discussion. GUI JavaBeans are treated like other GUI controls in DB/C JX. JavaBean controls are located in panels and dialogs. The syntax for creating a bean control inside the resource definition string (the 2nd operand of the prepare statement) is: CONTROL = : or CONTROL = : : : where is an item number, the same as with other controls is the fully qualified Java class name for the JavaBean and are the horizontal and vertical sizes of the control The change statement is used to change the value of a bean control property. Here is the syntax for the statement that changes the value of a property: CHANGE , ; where is the resource variable contains comma delimited keyword=value pairs, including: ITEM= PROPERTY= INDEX= is the new value; it may be one or more literals or variables In the , ITEM and PROPERTY are required and INDEX is required only if the PROPERTY is indexed and must not be specified if the property is not indexed. The query statement is used to query the value of a bean control property. The syntax is: QUERY , ; where is the resource variable contains comma delimited keyword=value pairs, including: ITEM= PROPERTY= INDEX= is one or more destination variables In the , ITEM and PROPERTY are required and INDEX is required only if the PROPERTY is indexed and must not be specified if the property is not indexed. The property values that are supported via the change and query statements with this syntax are these Java types: byte, Byte, short, Short, int, Integer, long, Long, float, Float, double, Double, char, Character, String All of these types except char, Character and String are treated as numeric types in the DB/C variables. Thus, for the change statement, the must be a valid numeric value. For char and Character, the first character of the is used as the new value. For property values that are other Java objects, this new syntax for change and query statements is used: CHANGE , ; QUERY , ; where and are the same as before is a DB/C object variable The April 1998 DB/C Newsletter describes a generalized Java interface for calling Java methods in any Java class. This interface can be used to deal with object variables that refer to Java instances instead of DB/C instances. If you want to call the Java methods of the JavaBeans directly, you can retrieve the actual instance of the bean control with a query statement that has this syntax: QUERY , "ITEM=, OBJECT"; JavaBeans produce events in response to user actions and other things. In Java programs these events are sent as instances of the various subclasses of java.util.EventObject. These EventObjects are sent to other objects that have registered as Event Listeners. The DB/C JX runtime support classes act as Event Listeners for all events created by JavaBeans that are used in GUI resources. For the standard events, the information in the EventObjects is translated into the normal ITEM, PUSH, MENU and PICK messages that are created by buttons, menus, list boxes, etc. Here is the list of Java GUI (AWT) events and how they are mapped to the DB/C QUEUE variable messages: - Java EventObject - ------------------- DB/C message ------------------- ActionEvent if JavaBean name contains "menu" then "MENU" message else if name contains "button" then "PUSH" message otherwise "PICK" message AdjustmentEvent "SB??" message (scroll bar messages) ComponentEvent no message ContainerEvent no message FocusEvent if focus is gained then "FOCS" message if focus is lost then "FOCL" message ItemEvent "ITEM" message KeyEvent no message (handled by window) MouseEvent no message (handled by window) MouseMotionEvent no message (handled by window) TextEvent "ITEM" message WindowEvent no message (handled by window) For each of these standard messages, the DB/C message format is the same as in DB/C 9.1. There is one other EventObject subclass that is specific to JavaBeans. This is the PropertyChangeEvent. A PropertyChangeEvent is created when a 'bound' or 'constrained' JavaBean property is changed. Properties are defined as 'bound' and/or 'constrained' by the creator of the JavaBean. A 'bound' property sends a PropertyChangeEvent to an object that has registered as a PropertyChangeListener for that JavaBean after the value of the property has changed. The purpose of this action is notification of property value changes. A 'constrained' property sends a PropertyChangeEvent to an object that has registered as a VetoableChangeListener for that JavaBean before the value of the property has been permanently changed. The purpose of this action is to allow other objects to 'veto' (cancel) the property change. In a Java program, the veto is done by throwing a PropertyVetoException. DB/C acts as a Listener for both of these situations. When the event is sent to the PropertyChangeListener method, DB/C produces a "PCHG" message. When the event is sent to the VetoableChangeListener method, DB/C produces a "VCHG" method. The format of these messages is as follows: characters 1- 8 resource name characters 9- 12 message type: "PCHG" or "VCHG" characters 13- 17 = item number of bean control characters 18-end (if non-indexed property) or [] (if indexed property) Example: resource name: "DIALOG01" message type: "PCHG" item number: "00101" property name: "SIZE" An example of an indexed property name: property name: "TEXT[3]" To veto a change, you need to do the following: 1. Synchronize the message receipt process with the Java GUI subsystem by using the DISABLE statement. 2. Execute the CHANGE statement with the VETO keyword. Here is an example: Q1 QUEUE SIZE=64 MSG RECORD NAME CHAR 8 FUNC CHAR 4 ITEM CHAR 5 DATA CHAR 47 RECORDEND LOOP WAIT Q1 DISABLE GET Q1; MSG IF (MSG.FUNC = "VCHG") CHANGE DLGRES, ("ITEM=" + MSG.ITEM + ",PROPERTY=" + MSG.DATA + ",VETO") ENDIF ENABLE REPEAT If the property is indexed, then MSG.DATA would need to be parsed so that the INDEX= keyword could be included in the string. In real programs, you probably would base the decision to veto a change based on the new value of the change. Thus, a QUERY statement would be used to retrieve the new (temporary) value of the property before the CHANGE VETO statement would be executed. This discussion may appear somewhat complicated on first reading, but in reality only a few new features were added to DB/C to support JavaBeans. The combination of the ease of use of the DB/C language with the extensibility of JavaBeans is hard to beat. ***************************************************************************** DB/C Class Schedule Class: DB/C DX and JX Language Fundamentals Date: January 1999 (tentative) Location: Oak Brook, Illinois For information, contact Judi Tamkevic at: voice 630.572.0240 email dbc@swc.com ***************************************************************************** Subscribing to the DB/C Newsletter If you don't already have the DB/C Newsletter delivered to your email address and would like to have it emailed to you when it is produced, just send an email message to 'request@swc.com' and put the line 'subscribe dbcnews' in the body of the email message (omit the ' characters). The newsletter will be delivered to the email address from which the message was sent. To stop delivery, put the line 'unsubscribe dbcnews' in the body of the message.