Desktop Integration Guide
  Search only this book
Download this book in PDF

Vendor Data Type Registration

C

If you want your application to be able to exchange data with other applications on the OpenWindows Desktop, you need to make your application's file format, process types, object types, and file attributes public. SunSoft facilitates the dissemination of this information through its Developer Integration Format Registration (DIFR) program.
Registration is required for the three technologies discussed in this guide: drag and drop, Classing Engine, and the ToolTalk service. As data type information is gathered, SunSoft will make it available to other developers.
Call the number below for instructions on receiving your DIFR packet. The packet contains detailed information on the program, as well as the forms you need to register your data types.
Phone number: 1-510-460-3267.
The remainder of this appendix discusses the technical issues of why data types must be registered.

C.1 Drag and Drop Data Types

If an application is to receive a drop from a source application, the source application must send the data in a format readable by the receiving application. For example, if Text Editor wishes to drop data into Mail Tool, Text Editor must be able to provide the data in a format readable by Mail Tool. Conversely, if Mail Tool wishes to drop data into Text Editor, Mail Tool must be able to provide the data in a format Text Editor can read. Although the source
application is responsible for providing data in a format readable by the receiving application, it is important that the receiving application be able to receive data in some of the more common data formats such as ASCII, Sun raster imaging format, or PostScript page description language.
Programmatically, drag and drop handshaking works as follows: (1) data is selected from the source application; (2) the receiving application requests a list of the data formats in which the source application can send the drop; (3) the source application replies with a list of data formats; (4) the receiving application tells the source application which format it would like the data sent; (5) data is transferred.
The SunSoft data type registration program helps standardize the data format names by which applications request data formats from one another. All companies that wish to share their data with other applications are encouraged to register data format names for their application's data files. This name will be used by other applications to reference desired data formats.
Data format names, as well as additional format information, will be made available from SunSoft.

C.2 Classing Engine File Types and Attributes

As described in Chapter 5, "Classing Engine," File Manager and other applications identify a file's type with a unique identifier. Once the file is typed, the file's attributes can be determined.

C.2.1 File Type Identifiers

The file type identifier is used to derive a file's type. File type identifiers can be associated with a filename pattern (such as *.ps or *.wk), a unique string value within the file, or both. If the type-by-pattern method is used, you will need to register a file pattern. If the type-by-content method is used, you will need to register a content pattern, byte offset, and content data type (short, long, string). Two file type registration examples are shown below.
  1. Content Value = SSQLReport; Offset = 0; Type = string

    This file type can be identified by the string "SSQLReport" starting at byte zero.

  2. Content Value = 0x4d4d002a; Offset = 10; Type = long

This file can be identified by the longword value 0x4d4d002a starting at offset 10 (decimal) in the file.
It is important that your file identifier be unique. The best identifier is a string that identifies your company, the application, and the file type.

C.2.2 File Type Attributes

File type attributes are used to specify the correct method to open or read the file, print the file, and the display icon. The current Classing Engine database attributes are shown below. Refer to Chapter 5, "Classing Engine," for more information on these attributes.
Table C-1
AttributeDescription
TYPE_NAMEFile type name
TYPE_OPENString used to open the file
TYPE_PRINTString used to print the file
TYPE_ICONicon file

$OPENWINHOME/include/images/compress.icon

TYPE_ICON_MASKicon-file,

<$OPENWINHOME/include/images/doc.mask.icon

TYPE_FGCOLORIcon foreground color
TYPE_BGCOLORIcon background color
TYPE_OPEN_TTToolTalk identifier used when starting applications
TYPE_FILE_TEMPLATEUnique filename generated a nd used by the application as a filename.

C.2.3 File Type and Attribute Reference

If you want to peruse a file of previously registered file types, you may view the Classing Engine database by using the program map1.c in the Classing Engine chapter, or use the ce_db_build utility to create an ASCII description file.

C.3 ToolTalk Type Information

ToolTalk messages can be addressed to a specific application, a type of application, a specific object, or a type of object. To send messages addressed to types of applications or objects, you must know the application's process type or object type. It is the name of an application's process types and object types that need to be registered. For more information on process and object types, see the ToolTalk User's Guide.
To provide process type and/or object type information to the ToolTalk service you must supply static type information at installation time by compiling your type file (which puts your type information into the Classing Engine database) and register your process type with the ToolTalk service. When you register your ptype with the ToolTalk service, it will read the type information from the Classing Engine database. If you use otypes, you need to also create a ptype for your application.

C.3.1 Process Type

To send messages to a particular type of application, an application needs to know the process type (ptype) of the receiving application(s). The ptype is identified by the process type identifier (ptid). A ptid must be unique for every installation. This identifier cannot be changed at installation time, so it is important that a unique name be chosen. Ideally you will use a name that includes the trademarked name of your product or company, such as Sun_EditDemo. Also use upper-case letters to help make your ptid unique. The ptid cannot exceed 32 characters, and should not be one of the reserved identifiers (start, queue, file, session, observe, handle, ptype, otype, per_file, per_session, and opnum.

C.3.2 Object Type

To send messages to a particular type of object, an application needs to know the object type (otype). The otype is identified by the object type identifier (otid). An otid must be unique for every installation. This identifier cannot be changed at installation time, so it is important that a unique name be chosen. It is recommended that the name begin with the ptid of the tool that implements the otype; e.g., Sun_EditDemo_object. The otid is limited to 64 characters, and should not be one of the reserved identifiers (start, queue, file, session, observe, handle, ptype, otype, per_file, per_session, and opnum).

C.3.3 Ptype and Otype Reference

If you want to peruse a file of previously registered ptypes and otypes, you may view the Classing Engine database by using tt_type_comp. Refer to the ToolTalk User's Guide for details.