Compaq DECwindows Motif
for OpenVMS
Release Notes


Previous Contents Index

4.8.1.2 Converting Files That Contain Asian-Language Characters

V1.2--3

You can convert an Asian-language text file to another format by specifying an options file or by defining the logical names DDIF$READ_TEXT_GL and DDIF$READ_TEXT_GR as discussed in Section 4.8.1.1.1 and Section 4.8.1.1.2.

The format for converting a document from TEXT to another format is as follows:


$ CONVERT/DOCUMENT/OPTION=language.CDA$OPTIONS filename.TXT/FORMAT=TEXT -
_$ filename.output_extension/FORMAT=output_format

For example, to convert a traditional Chinese language text file to a DDIF file, enter the following command line:


$ CONVERT/DOCUMENT/OPTION=HANYU.CDA$OPTIONS -
_$ GUIDELINES_PERSONNEL.TXT/FORMAT=TEXT  GUIDELINES_PERSONNEL.DDIF

Note that this command line does not include the /FORMAT=DDIF qualifier; DDIF is the default.

The output file, GUIDELINES_PERSONNEL.DDIF, contains language data.

You can also create Asian language PostScript files from a DDIF, DTIF, or text (ASCII) file. For example, to convert a DDIF file to PostScript (.PS) format, enter the following command:


$ CONVERT/DOCUMENT filename.DDIF filename.PS/FORMAT=PS

Note

Convert only DDIF and DTIF files that contain language data to Asian language PostScript format.

When you print an Asian language PostScript file on a PostScript printer, ensure that the required language fonts are available on the printer. Otherwise, the PostScript file defaults to a basic set of fonts. If these fonts do not exist, the PostScript file defaults to Courier fonts. Table 4-7 shows the languages and their associated basic fonts.

Table 4-7 Languages and Associated Basic Fonts
Language Basic Fonts
Japanese Ryumin-Light-EUC-H or Ryumin-Light-Hankaku
Hanyu Sung-Light-CNS11643, Sung-Light-DTSCS
Hangul Munjo
Hanzi XiSong-GB2312-80

Note

Vertical writing is not supported by the CDA converters. All vertical text is printed horizontally.

4.9 XNL Library

This section contains information about the XNL library.

4.9.1 Changes and Enhancements

The following notes describe changes and enhancements made to the XNL library.

4.9.1.1 xnl_parsedatetime

V1.2--5

xnl_parsedatetime (and its VAX binding, XNL$PARSE_DATE_TIME) accepts two-digit or four-digit years in the input argument XmString s (which is the date-time string to be parsed). Valid years in the two-digit format are in the range 70 to 99, which mean the years from 1970 to 1999. Values from 00 to 69 are invalid. Year 2000 and later must be specified in the four-digit format.

4.9.1.2 xnl_langinfo

V1.2--5

xnl_langinfo (and its VAX binding, XNL$LANGINFO) returns a string for date-time formatting when D_FMT or D_T_FMT is specified in the item argument. In the locales listed below, this function returns a formatting string containing %y. This formatting string should be used carefully after the year 2000, as %y indicates the two-digit year format.

4.10 Xlib

This section contains information about Xlib.

4.10.1 Changes and Enhancements

The following notes describe changes and enhancements made to the Xlib.

4.10.1.1 X11 Environment Variable Parsing

V1.2--6

Xlib now accepts the equivalent X11 Release 5 (X11 R5) forms of the following environment variables:
OpenVMS Form X11 R5 Form
DECW$DISPLAY DISPLAY
DECW$RESOURCE_NAME RESOURCE_NAME

On startup, if the OpenVMS variable is not defined, Xlib then checks for the X11 R5 equivalent before returning a status value.

4.10.1.2 UIDPATH Environment Variable

V1.2--6

When opening a hierarchy, Xlib searches the DECW$USER_DEFAULTS and DECW$SYSTEM_DEFAULTS areas for the User Interface Definition (UID) file. On UNIX systems and according to X11 R5 specifications, the search path is defined using the UIDPATH variable and its fallbacks.

Now, Xlib also checks for the UIDPATH variable if the UID file is not found using either of the OpenVMS variables state above. This variable references a UNIX-style pathname (for example, /foo/bar) and allows the substitutions strings as specified by X11 standards. For more information on the UIDPATH variable, see the OSF/Motif Programmer's Reference.

Note

The UIDPATH variable does not work with OpenVMS directory specifications. Use the DECW$xxx_DEFAULTS logicals to specify OpenVMS-style search paths.

4.10.1.3 New Default Format for XtResolvePathname

V1.2--6

In XtResolvePathname, the default pathname is required to have certain properties when either no other path information is present in the call, or when it is referenced by the environment variable XFILESEARCHPATH. The former default OpenVMS format of the pathname consisted of a type-name-suffix substitution. The modified pathname now reflects the 6-part fallback, as specified by X11 Release 5.

The new pathname behavior is enabled by setting the DECW$VSW_COMPLIANT variable, as follows:


$ DEFINE DECW$VSW_COMPLIANT 1 

4.10.1.4 XtAppMainLoop Routine

V1.2--5

Previously, if a program entered its event loop, (for example, by calling XtAppMainLoop) without having opened a display or specified a timer or event flag for the program to wait for (by calling XtAppAddTimeout or XtAppAddInput), Xlib terminated the program with the following error message:


        X Toolkit Error: Error in XMultiplexInput 

Starting with DECwindows Motif Version 1.2--5 for OpenVMS, if there is nothing to wait for, Xlib stalls waiting for input instead of terminating with an error status.

To allow Xlib to process events at a later time, applications should provide some means of regaining control, such as specifying an event flag by calling XtAppAddInput.

4.10.1.5 Locale Support in OpenVMS Systems

V1.2--4

The locale support provided in DECwindows Motif Version 1.2--4 for OpenVMS is compatible with the locale support in the DEC C Run-Time Library. If you write internationalized applications using these functions in the locale environment, do the following:

4.10.1.6 Xlib Internationalization

V1.2

The X Window System Version 11, Release 5 (X11 R5) defines a number of services to support writing internationalized X applications. Internationalization of X is based on the concept of a locale. A locale defines the localized behavior of a program at run time. Locales affect Xlib by:

The X Window System defines a general methodology and a set of application programming interfaces (APIs) to standardize programming in X. Standards have not been established for implementing these internationalization features. Currently, the X11 R5 distribution makes two sample implementations of Xlib internationalization support available: Xsi and Ximp. In addition, Compaq provides an implementation called Xi18n. You can select which I18N implementation you want. All three implementations provide the same functionality through the same set of public APIs, but their underlying processing differs. These differences are described in the following sections.

4.10.1.6.1 Vendor Pluggable Layer

Compaq provides a general mechanism called the vendor pluggable layer, which allows you to choose your own internationalization implementations. Different implementations can be built as standalone shareable libraries and can be selected through the logical DECW$XVENDORLAYER.

If this logical is not defined, the mechanism searches for an internationalization implementation library in the following order:

If a shareable library is not found, the default is the Xi18n implementations that are already linked with Xlib.

The following functions act as interfaces between Xlib and the internationalization implementation shareable library:

When creating the Xsi or the Ximp shareable library, you need to know the names of the interfaces because they are defined within Xlib. Compaq recommends that you rename the functions during compilation by adding the following compilation flags:


/define=(- 
    "XDefaultString"="_XDefaultString",- 
    "XwcFreeStringList"="_XwcFreeStringList",- 
    "XwcTextListToTextProperty"="_XwcTextListToTextProperty",- 
    "XmbTextListToTextProperty"="_XmbTextListToTextProperty",- 
    "XwcTextPropertyToTextList"="_XwcTextPropertyToTextList",- 
    "XmbTextPropertyToTextList"="_XmbTextPropertyToTextList",- 
    "_XrmInitParseInfo"="__XrmInitParseInfo",- 
    "_XlcDefaultLoader"="__XlcDefaultLoader") 

4.10.1.6.2 Compaq Internationalization Xlib Implementation

The Compaq implementation (Xi18n) provides enhanced support and a stable internationalization environment. The Compaq implementation (Xi18n) provides the following advantages over the Xsi or Ximp environments provided with the X distribution:

4.10.1.7 XSelectAsyncEvent and XSelectAsyncInput Routines

V1.1

The XSelectAsyncEvent and XSelectAsyncInput routines allocate memory for the storage of AST delivery information. This memory is freed in the following ways:

The AST delivery information for subwindows is not freed by XDestroyWindow.

If you want to turn off AST notification for all event types within a given window and also free the AST delivery information, the client application can call XSelectAsyncEvent or XSelectAsyncInput passing the event_mask argument equal to minus one (all bits set) and the ast_routine argument equal to zero.

4.10.1.8 Command Procedure Builds .PEN Files

V1.0

To allow Pascal programs to inherit environment files for Xlib and Motif, execute the command procedure SYS$LIBRARY:DECW$PEN_BUILD.COM. This command procedure generates the DECW$XLIBDEF.PEN and DECW$MOTIF.PEN files. The .PEN files compile into Pascal programs faster than the provided .PAS files.

4.10.2 Corrections

The following notes describe the resolution of any problems specific to Xlib that previously resulted in an error or required a workaround.

4.10.2.1 UNIX Filename Emulation (Alpha Only)

V1.2--6

Previously, UNIX-style filenames with embedded path syntax "../" within functions such as XtResolvePathname and MrmOpenHierarchy were not handled correctly. While this syntax is highly unusual, it can occur when both the filename and the pathname contain a relative path specification.

This problem has been corrected; UNIX-style filenames with this embedded syntax are parsed as expected.

4.10.2.2 XmTextField Widget Switches Focus Correctly

V1.2--6

A crash no longer occurs when the losingFocus callback peforms an XtSetValues() on an XmTextField routine.

4.10.2.3 XrmoptionStickyArg Produces Correct Results

V1.2--6

Problems with the XrmoptionStickyArg routine have been corrected; this routine no longer returns incorrect results when referenced from the command line.

4.10.2.4 PAllHints Macro Corrected

V1.2--6

The value of the PAllHints macro in XUTILS.H has been corrected.

4.10.3 Problems and Restrictions

The following notes describe problems and restrictions that currently pertain to Xlib.

4.10.3.1 XtOpenDisplay Routine and Case Sensitivity

V1.2--6

In some cases the application name in XtOpenDisplay comes from argv[0], which represents the name of the application on the command line.

Be aware that case sensitivity must be preserved in such environments as when referencing ODS-5 system with case preservation enabled or when passing a user-defined argv list.

4.10.3.2 Parameter/Protocol Datasize Mismatches

V1.0

Several Xlib routines accept longword parameters that are not sent in their entirety in the X Protocol message to the server. In each case, the Xlib routine sends out only the least significant 16 bits of the parameter value. This is a constraint of the field size within the X Protocol message.

Table 4-8 lists routine names and the longword arguments that are sent only as 16-bit values.

Table 4-8 Routine Names and Arguments Sent as 16-Bit Values
Routine Name Routine Arguments
XAllocColorCells/ALLOC_COLOR_CELLS nplanes,npixels
XDrawArc/DRAW_ARC x,y,width,height, angle1,angle2
XDrawLine/DRAW_LINE x1,x2,x3,x4
XDrawPoint/DRAW_POINT x,y
XDrawRectangle/DRAW_RECTANGLE x,y,width,height
XDrawString/DRAW_STRING x,y
XDrawString16/DRAW_STRING16 x,y
XDrawText/DRAW_TEXT x,y
XDrawText16/DRAW_TEXT16 x,y
XFillArc/FILL_ARC x,y,width, height,angle1,angle2
XFillRectangle/FILL_RECTANGLE x,y,width,height


Chapter 5
Documentation Release Notes

This chapter describes corrections to the DECwindows Motif documentation.

5.1 Getting Started With the New Desktop

This section contains documentation corrections to the Getting Started With the New Desktop manual.

5.1.1 File Specification Incorrect

V1.2--5

A file specification for a command procedure in Getting Started With the New Desktop (part number AA-QUW1A-TE) is incorrect. The file specification appears in Section 3.4.9, paragraph 5, as follows:

"Optional DECwindows applications, such as DECwindows Notes, may not provide any information and therefore are not restarted. For such cases, there is a command procedure called disk$:[user.DT]SESSIONETC.COM that you can use to start any applications that cannot be restarted automatically. This procedure is analogous to the DECW$LOGIN.COM procedure in the traditional DECwindows environment."

The correct file specification is:

disk$:[user.DT.SESSIONS]SESSIONETC.COM

5.2 DECwindows Motif for OpenVMS Applications Guide

This section contains documentation corrections to the DECwindows Motif for OpenVMS Applications Guide manual.

5.2.1 Enhancing Information About the Finish Printing Option

V1.2--3

The section called "Printing Information" in the chapter on DECterm provides information about the Print menu. To further clarify the information in the Finish Printing section, note the following:

Selecting the Finish Printing option on the Print menu closes the print job and toggles Auto Print mode back to Normal Print mode.

5.3 Using DECwindows Motif for OpenVMS

This section contains documentation corrections and enhancements to the Using DECwindows Motif for OpenVMS manual.

5.3.1 Using the Drag-and-Drop Feature

V1.2

The drag-and-drop feature lets you move or copy screen objects. For example, you can move text from buttons and paste it elsewhere.

To drag and drop text into a new location:

  1. Select the text to be copied or moved with MB1.
  2. To move the text, press and hold MB2; to copy the text, press and hold Ctrl/MB2.
    A move or copy icon appears.
  3. Drag the icon to the location where you want to drop the text and release MB2.
    If the object is highlighted as you drag the icon across it, you can drop the text into that location.

Drag-and-drop is provided primarily for programmers to incorporate the feature into their applications.

The DECwindows Motif Version 1.2 for OpenVMS applications support the drag-and-drop feature, with the exception of Notepad. DECwindows Mail supports drag-and-drop in all windows except the main message area, where DECwindows Mail has its own drag-and-drop feature; you can use MB2 to move messages around with the SVN interface.

5.3.2 Using Tear-Off Menus

V1.2--3

The DECwindows Mail application supports tear-off menus.

V1.2

The DECwindows Motif applications allow you to tear off pull-down and popup menus. Tear-off menus let you keep frequently used menus displayed without repeatedly pulling them down or popping them up.

To tear off a menu:

  1. Display a pull-down or popup menu.
    If the menu is a tear-off menu, a dotted line is displayed at the top of the menu.
  2. Click on the dotted line with MB1.
    The menu remains active until it is closed or until the parent application is closed.

To close a tear-off menu:

  1. Click on the Window menu button in the tear-off menu.
  2. Choose the Close menu item.

The following applications do not support tear-off menus:

5.3.3 Adding Target Screen Options to Application Menu Items

V1.2

The example "Adding Target Screen Options to Application Menu Items" in Using DECwindows Motif for OpenVMS is incorrect. To correct the problem, remove the first occurrence of the following line:

$ select_qualifiers:

5.3.4 Changing the Startup Environment

V1.2

The example "Changing Your Logo" is incorrect. To correct the problem, change the following code example in step one:


$ COPY SYS$COMMON:[SYSMGR]DECW$PRIVATE_APPS_SETUP.TEMPLATE - 
_$ SYS$SPECIFIC:[SYSMANAGER]DECW$PRIVATE_APPS_SETUP.COM/LOG 

The code example should read as follows:


$ COPY SYS$COMMON:[SYSMGR]DECW$PRIVATE_APPS_SETUP.TEMPLATE - 
_$ SYS$SPECIFIC:[SYSMGR]DECW$PRIVATE_APPS_SETUP.COM/LOG 

5.3.5 Enhancing Startup Performance

V1.1

Extensive SYLOGIN.COM or LOGIN.COM command procedures slow down application startup. Many of the operations performed in a SYLOGIN.COM or LOGIN.COM are meaningless for DECwindows application startup. Therefore, the SYLOGIN.COM and LOGIN.COM files should be conditionalized for DECwindows application startup performance. When starting a DECwindows application, a minimum of SYLOGIN.COM and LOGIN.COM commands should be executed.

Typically, the commands that should be executed are the redefinition of DECW$USER_DEFAULTS (if present), and other logical name definitions if the user will be referencing them from within the context of a DECwindows application. The following code segment can be inserted into SYLOGIN.COM and LOGIN.COM immediately following the commands necessary for DECwindows:


$ mode = f$mode() 
$ tt_devname = f$trnlnm("TT") 
$ session_mgr_login = (mode .eqs. "INTERACTIVE") .and.  - 
      (f$locate("WSA",tt_devname) .ne. f$len(tt_devname)) 
$ session_detached_process = (mode .eqs. "INTERACTIVE") .and. - 
      (f$locate("MBA",tt_devname) .ne. f$len(tt_devname)) 
$ if session_mgr_login .or. session_detached_process then exit 

Applications continue to run even if these lines are not added to the SYLOGIN.COM and LOGIN.COM files.


Previous Next Contents Index