diff options
-rw-r--r-- | specs/CH01.xml | 767 |
1 files changed, 201 insertions, 566 deletions
diff --git a/specs/CH01.xml b/specs/CH01.xml index ad17cb8..7df45fa 100644 --- a/specs/CH01.xml +++ b/specs/CH01.xml @@ -40,36 +40,20 @@ <!-- .\" It is provided ``as is'' without express or implied warranty. --> <!-- .\" --> \& -<!-- .sp 1 --> -<!-- .ce 3 --> -\s+1<function>Chapter 1</function>\s-1 - -\s+1<function>Intrinsics and Widgets</function>\s-1 -<!-- .sp 2 --> -<!-- .if \n(GS .nr nh*hl 1 --> -<!-- .nr H1 1 --> -<!-- .nr H2 0 --> -<!-- .nr H3 0 --> -<!-- .nr H4 0 --> -<!-- .nr H5 0 --> -<para> -<!-- .LP --> -<!-- .XS --> -<!-- <function>Chapter 1 \(em Intrinsics and Widgets</function> --> -<!-- .XE --> + +<chapter id='Intrinsics_and_Widgets'> +<title>Intrinsics and Widgets</title> +<sect1> +<para> The (xI are a programming library tailored to the special requirements of user interface construction within a network window system, specifically the X Window System. The (xI and a widget set make up an (tk. - </para> + <sect2 id="Intrinsics"> <title>Intrinsics</title> -<!-- .XS --> -<!-- <function>(SN Intrinsics</function> --> -<!-- .XE --> <para> -<!-- .LP --> The (xI provide the base mechanism necessary to build a wide variety of interoperating widget sets and application environments. The Intrinsics are a layer on top of Xlib, the @@ -78,8 +62,8 @@ fundamental abstractions provided by the X Window System while still remaining independent of any particular user interface policy or style. </para> + <para> -<!-- .LP --> The Intrinsics use object-oriented programming techniques to supply a consistent architecture for constructing and composing user interface components, known as widgets. This @@ -88,7 +72,6 @@ deriving new widgets from existing ones (subclassing) or by writing entirely new widgets following the established conventions. </para> <para> -<!-- .LP --> When the (xI were first conceived, the root of the object hierarchy was a widget class named Core. @@ -107,16 +90,12 @@ for each Intrinsics procedure and Chapter 12 describe which operations are defined for the nonwidget superclasses of Core. The reader may determine by context whether a specific reference to <emphasis remap='I'>widget</emphasis> actually means ``widget'' or ``object.'' - </para> </sect2> + <sect2 id="Languages"> <title>Languages</title> -<!-- .XS --> -<!-- <function>(SN Languages</function> --> -<!-- .XE --> <para> -<!-- .LP --> The Intrinsics are intended to be used for two programming purposes. Programmers writing widgets will be using most of the facilities provided by the @@ -135,8 +114,8 @@ from the C language. In these cases, the usual C programming conventions apply. In this specification, the term <emphasis remap='I'>client</emphasis> refers to any module, widget, or application that calls an Intrinsics procedure. </para> + <para> -<!-- .LP --> Applications that use the (xI mechanisms must include the header files <function>< X11/Intrinsic.h ></function> @@ -153,7 +132,6 @@ instead of <function>< X11/Intrinsic.h >.</function> </para> <para> -<!-- .LP --> The applications must also include the additional header files for each widget class that they are to use (for example, <function>< X11/Xaw/Label.h ></function> @@ -166,13 +144,10 @@ and is usually referenced as \-lXt when linking the application. </para> </sect2> + <sect2 id="Procedures_and_Macros"> <title>Procedures and Macros</title> <para> -<!-- .LP --> -<!-- .XS --> -<!-- <function>(SN Procedures and Macros</function> --> -<!-- .XE --> All functions defined in this specification except those specified below may be implemented as C macros with arguments. C applications may use ``#undef'' to remove a macro definition and ensure that the actual function @@ -181,31 +156,24 @@ has the same precedence as a function call and that evaluates each of its arguments exactly once, fully protected by parentheses, so that arbitrary expressions may be used as arguments. </para> + <para> -<!-- .LP --> The following symbols are macros that do not have function equivalents and that may expand their arguments in a manner other than that described above: -<function>XtCheckSubclass ,</function> -<function>XtNew ,</function> -<function>XtNumber ,</function> -<function>XtOffsetOf ,</function> -<function>XtOffset ,</function> +<function>XtCheckSubclass</function>, +<function>XtNew</function>, +<function>XtNumber</function>, +<function>XtOffsetOf</function>, +<function>XtOffset</function>, and -<function>XtSetArg .</function> - +<function>XtSetArg</function>. </para> </sect2> + <sect2 id="Widgets"> <title>Widgets</title> <para> -<!-- .LP --> -<!-- .XS --> -<!-- <function>(SN Widgets</function> --> -<!-- .XE --> -</para> -<para> -<!-- .LP --> The fundamental abstraction and data type of the (tk is the widget, which is a combination of an X window and its associated input and display semantics @@ -216,8 +184,8 @@ Some widgets are output-only and do not react to pointer or keyboard input, and others change their display in response to input and can invoke functions that an application has attached to them. </para> + <para> -<!-- .LP --> Every widget belongs to exactly one widget class, which is statically allocated and initialized and which contains the operations allowable on widgets of that class. @@ -235,16 +203,16 @@ which takes place when the first widget of the class or subclass is created.) For further information, see Section 2.5. </para> + <para> -<!-- .LP --> The distribution of the declarations and code for a new widget class among a public .h file for application programmer use, a private .h file for widget programmer use, and the implementation .c file is described in Section 1.6. The predefined widget classes adhere to these conventions. </para> + <para> -<!-- .LP --> A widget instance is composed of two parts: </para> <itemizedlist> @@ -260,26 +228,21 @@ all widgets of that class. </para> </listitem> </itemizedlist> + <para> -<!-- .LP --> Much of the input/output of a widget (for example, fonts, colors, sizes, or border widths) is customizable by users. </para> + <para> -<!-- .LP --> This chapter discusses the base widget classes, Core, Composite, and Constraint, and ends with a discussion of widget classing. - </para> + <sect3 id="Core_Widgets"> <title>Core Widgets</title> -<!-- .XS --> -<!-- (SN Core Widgets --> -<!-- .XE --> <para> -<!-- .LP --> -<!-- .IN "Core" "" "@DEF@" --> The Core widget class contains the definitions of fields common to all widgets. @@ -290,26 +253,17 @@ which is defined by the and <function>CorePart</function> structures. - </para> + <sect4 id="CoreClassPart_Structure"> <title>CoreClassPart Structure</title> -<!-- .XS --> -<!-- (SN CoreClassPart Structure --> -<!-- .XE --> <para> -<!-- .LP --> All widget classes contain the fields defined in the <function>CoreClassPart</function> structure. </para> -<para> -<!-- .LP --> -<!-- .IN "CoreClassPart" "" "@DEF@" --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3.5i --> -<!-- .ta .5i 3.5i --> typedef struct { WidgetClass superclass; See Section 1.6 String class_name; See Chapter 9 @@ -345,10 +299,8 @@ typedef struct { XtPointer extension; See Section 1.6 } CoreClassPart; </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> All widget classes have the Core class fields as their first component. The prototypical <function>WidgetClass</function> @@ -356,64 +308,46 @@ and <function>CoreWidgetClass</function> are defined with only this set of fields. </para> -<para> -<!-- .LP --> -<!-- .IN "Core" --> -<!-- .IN "WidgetClass" "" "@DEF@" --> -<!-- .IN "CoreWidgetClass" "" "@DEF@" --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3i --> -<!-- .ta .5i 3i --> typedef struct { CoreClassPart core_class; } WidgetClassRec, *WidgetClass, CoreClassRec, *CoreWidgetClass; </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> Various routines can cast widget class pointers, as needed, to specific widget class types. </para> + <para> -<!-- .LP --> The single occurrences of the class record and pointer for creating instances of Core are </para> + <para> -<!-- .LP --> In <function>IntrinsicP.h :</function> </para> + <para> -<!-- .LP --> -<!-- .sM --> <literallayout class="monospaced"> <!-- .TA .5i 3i --> <!-- .ta .5i 3i --> extern WidgetClassRec widgetClassRec; #define coreClassRec widgetClassRec </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> In <function>Intrinsic.h :</function> </para> -<para> -<!-- .LP --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3i --> -<!-- .ta .5i 3i --> extern WidgetClass widgetClass, coreWidgetClass; </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> The opaque types <function>Widget</function> and @@ -426,36 +360,20 @@ does not allow applications to access private data, the (xI use incomplete structure definitions in <function>Intrinsic.h :</function> </para> -<para> -<!-- .LP --> -<!-- .sM --> <literallayout class="monospaced"> -<!-- .TA .5i 3i --> -<!-- .ta .5i 3i --> typedef struct _WidgetClassRec *WidgetClass, *CoreWidgetClass; </literallayout> -<!-- .eM --> - -</para> </sect4> + <sect4 id="CorePart_Structure"> <title>CorePart Structure</title> -<!-- .XS --> -<!-- (SN CorePart Structure --> -<!-- .XE --> <para> -<!-- .LP --> All widget instances contain the fields defined in the <function>CorePart</function> structure. </para> -<para> -<!-- .LP --> -<!-- .IN "CorePart" "" "@DEF@" --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3i --> -<!-- .ta .5i 3i --> typedef struct _CorePart { Widget self; Described below WidgetClass widget_class; See Section 1.6 @@ -487,92 +405,57 @@ typedef struct _CorePart { Boolean mapped_when_managed; See Chapter 3 } CorePart; </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> All widget instances have the Core fields as their first component. The prototypical type <function>Widget</function> is defined with only this set of fields. </para> -<para> -<!-- .LP --> -<!-- .IN "Widget" "" "@DEF@" --> -<!-- .IN "CoreWidget" "" "@DEF@" --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3i --> -<!-- .ta .5i 3i --> typedef struct { CorePart core; } WidgetRec, *Widget, CoreRec, *CoreWidget; </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> Various routines can cast widget pointers, as needed, to specific widget types. </para> + <para> -<!-- .LP --> In order to make these types opaque and ensure that the compiler does not allow applications to access private data, the (xI use incomplete structure definitions in -<function>Intrinsic.h .</function> +<function>Intrinsic.h</function>. </para> -<para> -<!-- .LP --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3i --> -<!-- .ta .5i 3i --> typedef struct _WidgetRec *Widget, *CoreWidget; </literallayout> -<!-- .eM --> -</para> </sect4> <sect4 id="Core_Resources"> <title>Core Resources</title> <para> -<!-- .LP --> -<!-- .XS --> -<!-- <function>(SN Core Resources</function> --> -<!-- .XE --> -</para> -<para> -<!-- .LP --> -<!-- .IN "CoreWidget" "Resources" --> The resource names, classes, and representation types specified in the <function>coreClassRec</function> resource list are </para> -<para> -<!-- .LP --> + <informaltable> - <tgroup cols='4' align='center'> + <tgroup cols='3' align='center'> <colspec colname='c1'/> <colspec colname='c2'/> <colspec colname='c3'/> - <colspec colname='c4'/> <tbody> <row> - <entry>lw(1.5i) lw(1.5i) lw(2.5i) .</entry> - </row> - <row> - <entry>_</entry> - </row> - <row> <entry>Name</entry> <entry>Class</entry> <entry>Representation</entry> </row> <row> - <entry>_</entry> - </row> - <row> <entry>XtNaccelerators</entry> <entry>XtCAccelerators</entry> <entry>XtRAcceleratorTable</entry> @@ -622,101 +505,50 @@ resource list are <entry>XtCTranslations</entry> <entry>XtRTranslationTable</entry> </row> - <row> - <entry>_</entry> - </row> </tbody> </tgroup> </informaltable> -</para> + <para> -<!-- .LP --> Additional resources are defined for all widgets via the <function>objectClassRec</function> and <function>rectObjClassRec</function> resource lists; see Sections 12.2 and 12.3 for details. - </para> </sect4> + <sect4 id="CorePart_Default_Values"> <title>CorePart Default Values</title> -<!-- .XS --> -<!-- (SN CorePart Default Values --> -<!-- .XE --> <para> -<!-- .LP --> The default values for the Core fields, which are filled in by the (xI, from the resource lists, and by the initialize procedures, are </para> -<para> -<!-- .LP --> + <informaltable> - <tgroup cols='3' align='center'> + <tgroup cols='2' align='center'> <colspec colname='c1'/> <colspec colname='c2'/> - <colspec colname='c3'/> <tbody> <row> - <entry>lw(1.5i) lw(4.25i) .</entry> - </row> - <row> - <entry>_</entry> - </row> - <row> <entry>Field</entry> <entry>Default Value</entry> </row> <row> - <entry>_</entry> - </row> - <row> <entry>self</entry> <entry>Address of the widget structure (may not be changed).</entry> </row> <row> - <entry>T{</entry> - </row> - <row> <entry>widget_class</entry> - </row> - <row> - <entry>T}</entry> - <entry>T{</entry> - </row> - <row> - <entry><emphasis remap='I'>widget_class</emphasis> argument to</entry> - </row> - <row> - <entry><function>XtCreateWidget</function></entry> - </row> - <row> - <entry>(may not be changed).</entry> - </row> - <row> - <entry>T}</entry> - </row> - <row> - <entry>T{</entry> + <entry><emphasis remap='I'>widget_class</emphasis> argument to + <function>XtCreateWidget</function> + (may not be changed).</entry> </row> <row> <entry>parent</entry> - </row> - <row> - <entry>T}</entry> - <entry>T{</entry> - </row> - <row> - <entry><emphasis remap='I'>parent</emphasis> argument to</entry> - </row> - <row> - <entry><function>XtCreateWidget</function></entry> - </row> - <row> - <entry>(may not be changed).</entry> - </row> - <row> - <entry>T}</entry> + <entry><emphasis remap='I'>parent</emphasis> argument to + <function>XtCreateWidget</function> + (may not be changed).</entry> </row> <row> <entry>being_destroyed</entry> @@ -751,81 +583,31 @@ from the resource lists, and by the initialize procedures, are <entry>1</entry> </row> <row> - <entry>T{</entry> - </row> - <row> <entry>managed</entry> - </row> - <row> - <entry>T}</entry> - <entry>T{</entry> - </row> - <row> <entry><function>False</function></entry> </row> <row> - <entry>T}</entry> - </row> - <row> - <entry>T{</entry> - </row> - <row> <entry>sensitive</entry> - </row> - <row> - <entry>T}</entry> - <entry>T{</entry> - </row> - <row> <entry><function>True</function></entry> </row> <row> - <entry>T}</entry> - </row> - <row> <entry>ancestor_sensitive</entry> - <entry>T{</entry> - </row> - <row> - <entry>logical AND of parent's <emphasis remap='I'>sensitive</emphasis> and</entry> - </row> - <row> - <entry><emphasis remap='I'>ancestor_sensitive</emphasis> values.</entry> - </row> - <row> - <entry>T}</entry> + <entry>logical AND of parent's <emphasis remap='I'>sensitive</emphasis> and + <emphasis remap='I'>ancestor_sensitive</emphasis> values.</entry> </row> <row> <entry>accelerators</entry> <entry>NULL</entry> </row> <row> - <entry>T{</entry> - </row> - <row> <entry>border_pixel</entry> - </row> - <row> - <entry>T}</entry> - <entry>T{</entry> - </row> - <row> <entry><function>XtDefaultForeground</function></entry> </row> <row> - <entry>T}</entry> - </row> - <row> <entry>border_pixmap</entry> - <entry>T{</entry> - </row> - <row> <entry><function>XtUnspecifiedPixmap</function></entry> </row> <row> - <entry>T}</entry> - </row> - <row> <entry>popup_list</entry> <entry>NULL</entry> </row> @@ -834,45 +616,15 @@ from the resource lists, and by the initialize procedures, are <entry>0</entry> </row> <row> - <entry>T{</entry> - </row> - <row> <entry>name</entry> - </row> - <row> - <entry>T}</entry> - <entry>T{</entry> - </row> - <row> - <entry><emphasis remap='I'>name</emphasis> argument to</entry> - </row> - <row> - <entry><function>XtCreateWidget</function></entry> - </row> - <row> - <entry>(may not be changed).</entry> - </row> - <row> - <entry>T}</entry> - </row> - <row> - <entry>T{</entry> + <entry><emphasis remap='I'>name</emphasis> argument to + <function>XtCreateWidget</function> + (may not be changed).</entry> </row> <row> <entry>screen</entry> - </row> - <row> - <entry>T}</entry> - <entry>T{</entry> - </row> - <row> - <entry>Parent's <emphasis remap='I'>screen</emphasis>; top-level widget gets screen from display specifier</entry> - </row> - <row> - <entry>(may not be changed).</entry> - </row> - <row> - <entry>T}</entry> + <entry>Parent's <emphasis remap='I'>screen</emphasis>; top-level widget gets screen from display specifier + (may not be changed).</entry> </row> <row> <entry>colormap</entry> @@ -887,91 +639,39 @@ from the resource lists, and by the initialize procedures, are <entry>Parent's <emphasis remap='I'>depth</emphasis>; top-level widget gets root window depth.</entry> </row> <row> - <entry>T{</entry> - </row> - <row> <entry>background_pixel</entry> - </row> - <row> - <entry>T}</entry> - <entry>T{</entry> - </row> - <row> <entry><function>XtDefaultBackground</function></entry> </row> <row> - <entry>T}</entry> - </row> - <row> <entry>background_pixmap</entry> - <entry>T{</entry> - </row> - <row> <entry><function>XtUnspecifiedPixmap</function></entry> </row> <row> - <entry>T}</entry> - </row> - <row> - <entry>T{</entry> - </row> - <row> <entry>visible</entry> - </row> - <row> - <entry>T}</entry> - <entry>T{</entry> - </row> - <row> <entry><function>True</function></entry> </row> <row> - <entry>T}</entry> - </row> - <row> - <entry>T{</entry> - </row> - <row> <entry>mapped_when_managed</entry> - </row> - <row> - <entry>T}</entry> - <entry>T{</entry> - </row> - <row> <entry><function>True</function></entry> </row> - <row> - <entry>T}</entry> - </row> - <row> - <entry>_</entry> - </row> </tbody> </tgroup> </informaltable> -</para> + <para> -<!-- .LP --> -<!-- .IN XtUnspecifiedPixmap "" "@DEF@" --> <function>XtUnspecifiedPixmap</function> is a symbolic constant guaranteed to be unequal to any valid Pixmap id, -<function>None ,</function> +<function>None</function>, and -<function>ParentRelative .</function> - +<function>ParentRelative</function>. </para> </sect4> </sect3> + <sect3 id="Composite_Widgets"> <title>Composite Widgets</title> -<!-- .XS --> -<!-- (SN Composite Widgets --> -<!-- .XE --> <para> -<!-- .LP --> -<!-- .IN "Composite" "" "@DEF@" --> The Composite widget class is a subclass of the Core @@ -982,27 +682,18 @@ The additional data used by composite widgets are defined by the and <function>CompositePart</function> structures. - </para> + <sect4 id="CompositeClassPart_Structure"> <title>CompositeClassPart Structure</title> -<!-- .XS --> -<!-- (SN CompositeClassPart Structure --> -<!-- .XE --> <para> -<!-- .LP --> In addition to the Core class fields, widgets of the Composite class have the following class fields. </para> -<para> -<!-- .LP --> -<!-- .IN "CompositeClassPart" "" "@DEF@" --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3.5i --> -<!-- .ta .5i 3.5i --> typedef struct { XtGeometryHandler geometry_manager; See Chapter 6 XtWidgetProc change_managed; See Chapter 3 @@ -1011,10 +702,8 @@ typedef struct { XtPointer extension; See Section 1.6 } CompositeClassPart; </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> The extension record defined for <function>CompositeClassPart</function> with <emphasis remap='I'>record_type</emphasis> @@ -1023,14 +712,8 @@ equal to is <function>CompositeClassExtensionRec .</function> </para> -<para> -<!-- .LP --> -<!-- .IN "CompositeClassExtensionRec" "" "@DEF@" --> -<!-- .IN "CompositeClassExtension" "" "@DEF@" --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3.5i --> -<!-- .ta .5i 3.5i --> typedef struct { XtPointer next_extension; See Section 1.6.12 XrmQuark record_type; See Section 1.6.12 @@ -1040,65 +723,46 @@ typedef struct { Boolean allows_change_managed_set; See Section 3.4.3 } CompositeClassExtensionRec, *CompositeClassExtension; </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> Composite classes have the Composite class fields immediately following the Core class fields. </para> -<para> -<!-- .LP --> -<!-- .IN "CompositeWidgetClass" "" "@DEF@" --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3i --> -<!-- .ta .5i 3i --> typedef struct { CoreClassPart core_class; CompositeClassPart composite_class; } CompositeClassRec, *CompositeWidgetClass; </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> The single occurrences of the class record and pointer for creating instances of Composite are </para> + <para> -<!-- .LP --> In <function>IntrinsicP.h :</function> </para> -<para> -<!-- .LP --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3i --> -<!-- .ta .5i 3i --> extern CompositeClassRec compositeClassRec; </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> In <function>Intrinsic.h :</function> </para> -<para> -<!-- .LP --> -<!-- .sM --> + <literallayout class="monospaced"> <!-- .TA .5i 3i --> <!-- .ta .5i 3i --> extern WidgetClass compositeWidgetClass; </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> The opaque types <function>CompositeWidget</function> and @@ -1117,25 +781,15 @@ uses an incomplete structure definition to ensure that the compiler catches attempts to access private data. </para> -<para> -<!-- .LP --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3i --> -<!-- .ta .5i 3i --> typedef struct _CompositeClassRec *CompositeWidgetClass; </literallayout> -<!-- .eM --> - -</para> </sect4> + <sect4 id="CompositePart_Structure"> <title>CompositePart Structure</title> -<!-- .XS --> -<!-- (SN CompositePart Structure --> -<!-- .XE --> <para> -<!-- .LP --> In addition to the Core instance fields, @@ -1144,13 +798,7 @@ instance fields defined in the <function>CompositePart</function> structure. </para> -<para> -<!-- .LP --> -<!-- .IN "CompositePart" "" "@DEF@" --> -<!-- .sM --> <literallayout class="monospaced"> -<!-- .TA .5i 3i --> -<!-- .ta .5i 3i --> typedef struct { WidgetList children; See Chapter 3 Cardinal num_children; See Chapter 3 @@ -1158,53 +806,40 @@ typedef struct { XtOrderProc insert_position; See Section 3.2 } CompositePart; </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> Composite widgets have the Composite instance fields immediately following the Core instance fields. </para> -<para> -<!-- .LP --> -<!-- .IN "CompositeWidget" "" "@DEF@" --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3i --> -<!-- .ta .5i 3i --> typedef struct { CorePart core; CompositePart composite; } CompositeRec, *CompositeWidget; </literallayout> -</para> + <para> -<!-- .LP --> -<!-- .eM --> <function>Intrinsic.h</function> uses an incomplete structure definition to ensure that the compiler catches attempts to access private data. </para> -<para> -<!-- .LP --> -<!-- .sM --> + <literallayout class="monospaced"> -<!-- .TA .5i 3i --> -<!-- .ta .5i 3i --> typedef struct _CompositeRec *CompositeWidget; </literallayout> -<!-- .eM --> </para> </sect4> + <sect4 id="Composite_Resources"> <title>Composite Resources</title> <!-- .XS --> <!-- <function>(SN Composite Resources</function> --> <!-- .XE --> <para> -<!-- .LP --> + <!-- .IN "CompositeWidget" "Resources" --> The resource names, classes, and representation types that are specified in @@ -1213,7 +848,7 @@ the resource list are </para> <para> -<!-- .LP --> + <informaltable> <tgroup cols='4' align='center'> <colspec colname='c1'/> @@ -1265,7 +900,7 @@ resource list are <!-- (SN CompositePart Default Values --> <!-- .XE --> <para> -<!-- .LP --> + The default values for the Composite fields, which are filled in from the Composite @@ -1274,7 +909,7 @@ Composite initialize procedure, are </para> <para> -<!-- .LP --> + <informaltable> <tgroup cols='' align='center'> <tbody> @@ -1301,7 +936,7 @@ initialize procedure, are </informaltable> </para> <para> -<!-- .LP --> + The <emphasis remap='I'>children</emphasis>, <emphasis remap='I'>num_children</emphasis>, and <emphasis remap='I'>insert_position</emphasis> fields are declared as resources; @@ -1325,7 +960,7 @@ widget class procedures. <!-- (SN Constraint Widgets --> <!-- .XE --> <para> -<!-- .LP --> + <!-- .IN "Constraint" "" "@DEF@" --> The Constraint widget class is a subclass of the @@ -1347,7 +982,7 @@ structures. <!-- (SN ConstraintClassPart Structure --> <!-- .XE --> <para> -<!-- .LP --> + In addition to the Core and @@ -1357,7 +992,7 @@ widgets of the Constraint class have the following class fields. </para> <para> -<!-- .LP --> + <!-- .IN "ConstraintClassPart" "" "@DEF@" --> <!-- .sM --> <literallayout class="monospaced"> @@ -1375,7 +1010,7 @@ typedef struct { </literallayout> </para> <para> -<!-- .LP --> + <!-- .eM --> The extension record defined for <function>ConstraintClassPart</function> @@ -1385,7 +1020,7 @@ is <function>ConstraintClassExtensionRec .</function> </para> <para> -<!-- .LP --> + <!-- .IN "ConstraintClassExtensionRec" "" "@DEF@" --> <!-- .IN "ConstraintClassExtension" "" "@DEF@" --> <!-- .sM --> @@ -1402,14 +1037,14 @@ typedef struct { </literallayout> </para> <para> -<!-- .LP --> + <!-- .eM --> Constraint classes have the Constraint class fields immediately following the Composite class fields. </para> <para> -<!-- .LP --> + <!-- .IN "ConstraintWidgetClass" "" "@DEF@" --> <!-- .sM --> <literallayout class="monospaced"> @@ -1423,18 +1058,18 @@ typedef struct _ConstraintClassRec { </literallayout> </para> <para> -<!-- .LP --> + <!-- .eM --> The single occurrences of the class record and pointer for creating instances of Constraint are </para> <para> -<!-- .LP --> + In <function>IntrinsicP.h :</function> </para> <para> -<!-- .LP --> + <!-- .sM --> <literallayout class="monospaced"> <!-- .TA .5i 3i --> @@ -1443,13 +1078,13 @@ extern ConstraintClassRec constraintClassRec; </literallayout> </para> <para> -<!-- .LP --> + <!-- .eM --> In <function>Intrinsic.h :</function> </para> <para> -<!-- .LP --> + <!-- .sM --> <literallayout class="monospaced"> <!-- .TA .5i 3i --> @@ -1458,7 +1093,7 @@ extern WidgetClass constraintWidgetClass; </literallayout> </para> <para> -<!-- .LP --> + <!-- .eM --> The opaque types <function>ConstraintWidget</function> @@ -1479,7 +1114,7 @@ uses an incomplete structure definition to ensure that the compiler catches attempts to access private data. </para> <para> -<!-- .LP --> + <!-- .sM --> <literallayout class="monospaced"> <!-- .TA .5i 3i --> @@ -1496,7 +1131,7 @@ typedef struct _ConstraintClassRec *ConstraintWidgetClass; <!-- (SN ConstraintPart Structure --> <!-- .XE --> <para> -<!-- .LP --> + In addition to the Core and @@ -1508,7 +1143,7 @@ instance fields defined in the structure </para> <para> -<!-- .LP --> + <!-- .IN "ConstraintPart" "" "@DEF@" --> <!-- .sM --> <literallayout class="monospaced"> @@ -1520,14 +1155,14 @@ typedef struct { </literallayout> </para> <para> -<!-- .LP --> + <!-- .eM --> Constraint widgets have the Constraint instance fields immediately following the Composite instance fields. </para> <para> -<!-- .LP --> + <!-- .IN "ConstraintWidget" "" "@DEF@" --> <!-- .sM --> <literallayout class="monospaced"> @@ -1541,14 +1176,14 @@ typedef struct { </literallayout> </para> <para> -<!-- .LP --> + <!-- .eM --> <function>Intrinsic.h</function> uses an incomplete structure definition to ensure that the compiler catches attempts to access private data. </para> <para> -<!-- .LP --> + <!-- .sM --> <literallayout class="monospaced"> <!-- .TA .5i 3i --> @@ -1565,7 +1200,7 @@ typedef struct _ConstraintRec *ConstraintWidget; <!-- <function>(SN Constraint Resources</function> --> <!-- .XE --> <para> -<!-- .LP --> + The <function>constraintClassRec</function> <emphasis remap='I'>core_class</emphasis> and <emphasis remap='I'>constraint_class resources</emphasis> fields are NULL, @@ -1585,14 +1220,14 @@ Constraint. <!-- <function>(SN Implementation-Specific Types</function> --> <!-- .XE --> <para> -<!-- .LP --> + To increase the portability of widget and application source code between different system environments, the (xI define several types whose precise representation is explicitly dependent upon, and chosen by, each individual implementation of the (xI. </para> <para> -<!-- .LP --> + These implementation-defined types are <!-- .IN "Boolean" "" "@DEF@" --> </para> @@ -1674,7 +1309,7 @@ respectively. </listitem> </itemizedlist> <para> -<!-- .LP --> + In addition to these specific types, the precise order of the fields within the structure declarations for any of the instance part records @@ -1710,7 +1345,7 @@ fields may be assumed. <sect2 id="Widget_Classing"> <title>Widget Classing</title> <para> -<!-- .LP --> + <!-- .XS --> <!-- <function>(SN Widget Classing</function> --> <!-- .XE --> @@ -1727,7 +1362,7 @@ Such procedures are applicable to all widgets of that class and also to widgets whose classes are subclasses of that class. </para> <para> -<!-- .LP --> + All widget classes are a subclass of Core and can be subclassed further. @@ -1742,7 +1377,7 @@ Subclasses usually inherit many of their superclasses' procedures (for example, the expose procedure or geometry handler). </para> <para> -<!-- .LP --> + Subclassing, however, can be taken too far. If you create a subclass that inherits none of the procedures of its superclass, @@ -1750,7 +1385,7 @@ you should consider whether you have chosen the most appropriate superclass. </para> <para> -<!-- .LP --> + To make good use of subclassing, widget declarations and naming conventions are highly stylized. A widget consists of three files: @@ -1780,7 +1415,7 @@ A .c file, which implements the widget. <!-- <function>(SN Widget Naming Conventions</function> --> <!-- .XE --> <para> -<!-- .LP --> + The (xI provide a vehicle by which programmers can create new widgets and organize a collection of widgets into an application. To ensure that applications need not deal with as many styles of capitalization @@ -1899,7 +1534,7 @@ they start with a capital letter, and compound names use uppercase </listitem> </itemizedlist> <para> -<!-- .LP --> + The symbolic identifiers XtN..., XtC..., and XtR... may be implemented as macros, as global symbols, or as a mixture of the two. The @@ -1922,7 +1557,7 @@ simultaneously. <!-- (SN Widget Subclassing in Public .h Files --> <!-- .XE --> <para> -<!-- .LP --> + The public .h file for a widget class is imported by clients and contains </para> @@ -1965,12 +1600,12 @@ Entry points for new class methods. </listitem> </itemizedlist> <para> -<!-- .LP --> + For example, the following is the public .h file for a possible implementation of a Label widget: </para> <para> -<!-- .LP --> + <literallayout class="monospaced"> <!-- .TA .5i 1.75i --> <!-- .ta .5i 1.75i --> @@ -2003,13 +1638,13 @@ extern String LabelGetText(); </literallayout> </para> <para> -<!-- .LP --> + The conditional inclusion of the text allows the application to include header files for different widgets without being concerned that they already may be included as a superclass of another widget. </para> <para> -<!-- .LP --> + To accommodate operating systems with file name length restrictions, the name of the public .h file is the first ten characters of the widget class. @@ -2027,7 +1662,7 @@ widget class is <!-- (SN Widget Subclassing in Private .h Files --> <!-- .XE --> <para> -<!-- .LP --> + The private .h file for a widget is imported by widget classes that are subclasses of the widget and contains </para> @@ -2120,11 +1755,11 @@ An inherit constant for each new procedure in the widget class part structure. </listitem> </itemizedlist> <para> -<!-- .LP --> + For example, the following is the private .h file for a possible Label widget: </para> <para> -<!-- .LP --> + <literallayout class="monospaced"> <!-- .TA .5i 3i --> <!-- .ta .5i 3i --> @@ -2198,7 +1833,7 @@ extern LabelClassRec labelClassRec; </literallayout> </para> <para> -<!-- .LP --> + To accommodate operating systems with file name length restrictions, the name of the private .h file is the first nine characters of the widget class followed by a capital P. @@ -2216,7 +1851,7 @@ widget class is <!-- (SN Widget Subclassing in .c Files --> <!-- .XE --> <para> -<!-- .LP --> + The .c file for a widget contains the structure initializer for the class record variable, which contains the following parts: @@ -2247,7 +1882,7 @@ the widget). </listitem> </itemizedlist> <para> -<!-- .LP --> + <!-- .IN "superclass" "" "@DEF@" --> The <emphasis remap='I'>superclass</emphasis> field points to the superclass global class @@ -2261,7 +1896,7 @@ inheriting or enveloping a superclass's operations (see Sections 1.6.7, 1.6.9, and 1.6.10). </para> <para> -<!-- .LP --> + <!-- .IN "class_name" "" "@DEF@" --> The <emphasis remap='I'>class_name</emphasis> field contains the text name for this class, which is used by @@ -2274,14 +1909,14 @@ subsequently deallocated. </para> <para> -<!-- .LP --> + <!-- .IN "widget_size" "" "@DEF@" --> The <emphasis remap='I'>widget_size</emphasis> field is the size of the corresponding widget instance structure (not the size of the class structure). </para> <para> -<!-- .LP --> + <!-- .IN "version" "" "@DEF@" --> The <emphasis remap='I'>version</emphasis> field indicates the toolkit implementation version number and is used for @@ -2304,7 +1939,7 @@ allows the (xI implementation to recognize widget binaries that were compiled with older implementations. </para> <para> -<!-- .LP --> + The <emphasis remap='I'>extension</emphasis> field is for future upward compatibility. If the widget programmer adds fields to class parts, all subclass structure layouts change, @@ -2314,11 +1949,11 @@ an extension field at the end of each class part can point to a record that contains any additional class information required. </para> <para> -<!-- .LP --> + All other fields are described in their respective sections. </para> <para> -<!-- .LP --> + The .c file also contains the declaration of the global class structure pointer variable used to create instances of the class. The following is an abbreviated version of the .c file @@ -2326,7 +1961,7 @@ for a Label widget. The resources table is described in Chapter 9. </para> <para> -<!-- .LP --> + <literallayout class="monospaced"> <!-- .TA .5i 1.5i 3i --> <!-- .ta .5i 1.5i 3i --> @@ -2431,13 +2066,13 @@ void LabelSetText(w, text) <!-- (SN Widget Class and Superclass Look Up --> <!-- .XE --> <para> -<!-- .LP --> + To obtain the class of a widget, use <function>XtClass .</function> <!-- .IN "XtClass" "" "@DEF@" --> </para> <para> -<!-- .LP --> + <!-- .sM --> </para> <!-- .FD 0 --> @@ -2458,7 +2093,7 @@ Specifies the widget. (oI </varlistentry> </variablelist> <para> -<!-- .LP --> + <!-- .eM --> The <function>XtClass</function> @@ -2466,13 +2101,13 @@ function returns a pointer to the widget's class structure. <!-- .sp --> </para> <para> -<!-- .LP --> + To obtain the superclass of a widget, use <function>XtSuperclass .</function> <!-- .IN "XtSuperclass" "" "@DEF@" --> </para> <para> -<!-- .LP --> + <!-- .sM --> </para> <!-- .FD 0 --> @@ -2493,7 +2128,7 @@ Specifies the widget. (oI </varlistentry> </variablelist> <para> -<!-- .LP --> + <!-- .eM --> The <function>XtSuperclass</function> @@ -2507,13 +2142,13 @@ function returns a pointer to the widget's superclass class structure. <!-- (SN Widget Subclass Verification --> <!-- .XE --> <para> -<!-- .LP --> + To check the subclass to which a widget belongs, use <function>XtIsSubclass .</function> <!-- .IN "XtIsSubclass" "" "@DEF@" --> </para> <para> -<!-- .LP --> + <!-- .sM --> </para> <!-- .FD 0 --> @@ -2546,7 +2181,7 @@ Specifies the widget class for which to test. (oC </varlistentry> </variablelist> <para> -<!-- .LP --> + <!-- .eM --> The <function>XtIsSubclass</function> @@ -2563,7 +2198,7 @@ to find out if a widget belongs to the desired class of objects. <!-- .sp --> </para> <para> -<!-- .LP --> + To test if a given widget belongs to a subclass of an (xI-defined class, the (xI define macros or functions equivalent to <function>XtIsSubclass</function> @@ -2597,11 +2232,11 @@ and <!-- .IN "XtIsSessionShell" "" "@DEF@" --> </para> <para> -<!-- .LP --> + All these macros and functions have the same argument description. </para> <para> -<!-- .LP --> + <!-- .sM --> </para> <!-- .FD 0 --> @@ -2622,7 +2257,7 @@ Specifies the widget or object instance whose class is to be checked. (oI </varlistentry> </variablelist> <para> -<!-- .LP --> + <!-- .eM --> These procedures may be faster than calling <function>XtIsSubclass</function> @@ -2630,7 +2265,7 @@ directly for the built-in classes. <!-- .sp --> </para> <para> -<!-- .LP --> + To check a widget's class and to generate a debugging error message, use <function>XtCheckSubclass ,</function> @@ -2639,7 +2274,7 @@ defined in <!-- .IN "XtCheckSubclass" "" "@DEF@" --> </para> <para> -<!-- .LP --> + <!-- .sM --> </para> <!-- .FD 0 --> @@ -2685,7 +2320,7 @@ Specifies the message to be used. </varlistentry> </variablelist> <para> -<!-- .LP --> + <!-- .eM --> The <function>XtCheckSubclass</function> @@ -2703,7 +2338,7 @@ should be used at the entry point of exported routines to ensure that the client has passed in a valid widget class for the exported operation. </para> <para> -<!-- .LP --> + <function>XtCheckSubclass</function> is only executed when the module has been compiled with the compiler symbol DEBUG defined; otherwise, it is defined as the empty string @@ -2717,7 +2352,7 @@ and generates no code. <!-- (SN Superclass Chaining --> <!-- .XE --> <para> -<!-- .LP --> + <!-- .IN "Chaining" "superclass" --> <!-- .IN "Chaining" "Subclass" --> <!-- .IN "Superclass Chaining" "" "@DEF@" --> @@ -2783,7 +2418,7 @@ In Shell widget classes: <emphasis remap='I'>root_geometry_manager</emphasis> <!-- .sp --> </para> <para> -<!-- .LP --> + With downward superclass chaining, the invocation of an operation first accesses the field from the Object, @@ -2811,7 +2446,7 @@ that widget's class structure. These superclass-to-subclass fields are <!-- .sp --> </para> <para> -<!-- .LP --> + In addition, for subclasses of Constraint, the following fields of the @@ -2833,7 +2468,7 @@ class down to the subclass: <!-- .sp --> </para> <para> -<!-- .LP --> + With upward superclass chaining, the invocation of an operation first accesses the field from the widget class structure, then from the superclass structure, @@ -2853,7 +2488,7 @@ The subclass-to-superclass fields are <!-- .sp --> </para> <para> -<!-- .LP --> + For subclasses of Constraint, the following field of @@ -2873,7 +2508,7 @@ Constraint class: <!-- (SN Class Initialization: class_initialize and class_part_initialize Procedures --> <!-- .XE --> <para> -<!-- .LP --> + <!-- .IN "Class Initialization" --> <!-- .IN "Initialization" --> Many class records can be initialized completely at compile or link time. @@ -2882,7 +2517,7 @@ a class may need to register type converters or perform other sorts of once-only runtime initialization. </para> <para> -<!-- .LP --> + Because the C language does not have initialization procedures that are invoked automatically when a program starts up, a widget class can declare a class_initialize procedure @@ -2893,20 +2528,20 @@ A class initialization procedure pointer is of type <!-- .IN "XtProc" "" "@DEF@" --> </para> <para> -<!-- .LP --> + <!-- .sM --> </para> <!-- .FD 0 --> typedef void (*XtProc)(void); <!-- .FN --> <para> -<!-- .LP --> + <!-- .eM --> A widget class indicates that it has no class initialization procedure by specifying NULL in the <emphasis remap='I'>class_initialize</emphasis> field. </para> <para> -<!-- .LP --> + In addition to the class initialization that is done exactly once, some classes perform initialization for fields in their parts of the class record. @@ -2919,7 +2554,7 @@ The class_part_initialize procedure pointer is of type <!-- .IN "XtWidgetClassProc" "" "@DEF@" --> </para> <para> -<!-- .LP --> + <!-- .sM --> </para> <!-- .FD 0 --> @@ -2940,7 +2575,7 @@ Points to the class structure for the class being initialized. </varlistentry> </variablelist> <para> -<!-- .LP --> + <!-- .eM --> During class initialization, the class part initialization procedures for the class and all its superclasses @@ -2971,13 +2606,13 @@ or that need no extra processing for them can specify NULL in the <emphasis remap='I'>class_part_initialize</emphasis> field. </para> <para> -<!-- .LP --> + All widget classes, whether they have a class initialization procedure or not, must start with their <emphasis remap='I'>class_inited</emphasis> field <function>False .</function> </para> <para> -<!-- .LP --> + The first time a widget of a class is created, <function>XtCreateWidget</function> ensures that the widget class and all superclasses are initialized, in @@ -2991,11 +2626,11 @@ After the one-time initialization, a class structure is constant. </para> <para> -<!-- .LP --> + The following example provides the class initialization procedure for a Label class. </para> <para> -<!-- .LP --> + <literallayout class="monospaced"> <!-- .TA .5i 2i --> <!-- .ta .5i 2i --> @@ -3015,7 +2650,7 @@ static void ClassInitialize() <!-- .XE --> <!-- .IN "Widget" "class initialization" --> <para> -<!-- .LP --> + A class is initialized when the first widget of that class or any subclass is created. To initialize a widget class without creating any widgets, use @@ -3023,7 +2658,7 @@ To initialize a widget class without creating any widgets, use <!-- .IN "XtInitializeWidgetClass" "" "@DEF@" --> </para> <para> -<!-- .LP --> + <!-- .sM --> </para> <!-- .FD 0 --> @@ -3047,14 +2682,14 @@ or any subclass thereof. </varlistentry> </variablelist> <para> -<!-- .LP --> + <!-- .eM --> If the specified widget class is already initialized, <function>XtInitializeWidgetClass</function> returns immediately. </para> <para> -<!-- .LP --> + If the class initialization procedure registers type converters, these type converters are not available until the first object of the class or subclass is created or @@ -3070,7 +2705,7 @@ is called <!-- (SN Inheritance of Superclass Operations --> <!-- .XE --> <para> -<!-- .LP --> + A widget class is free to use any of its superclass's self-contained operations rather than implementing its own code. The most frequently inherited operations are @@ -3108,14 +2743,14 @@ set_values_almost </listitem> </itemizedlist> <para> -<!-- .LP --> + To inherit an operation <emphasis remap='I'>xyz</emphasis>, specify the constant <function>XtInherit <emphasis remap='I'>Xyz</emphasis></function> in your class record. </para> <para> -<!-- .LP --> + Every class that declares a new procedure in its widget class part must provide for inheriting the procedure in its class_part_initialize procedure. @@ -3127,7 +2762,7 @@ specify NULL for chained procedures in their class records. </para> <para> -<!-- .LP --> + Inheriting works by comparing the value of the field with a known, special value and by copying in the superclass's value for that field if a match occurs. @@ -3139,13 +2774,13 @@ cast to the appropriate type. is a procedure that issues an error message if it is actually called. </para> <para> -<!-- .LP --> + For example, <function>CompositeP.h</function> contains these definitions: </para> <para> -<!-- .LP --> + <literallayout class="monospaced"> <!-- .TA .25i 1.5i 3i --> <!-- .ta .25i 1.5i 3i --> @@ -3156,11 +2791,11 @@ contains these definitions: </literallayout> </para> <para> -<!-- .LP --> + Composite's class_part_initialize procedure begins as follows: </para> <para> -<!-- .LP --> + <literallayout class="monospaced"> <!-- .TA .2i 1.5i 3i --> <!-- .ta .2i 1.5i 3i --> @@ -3183,14 +2818,14 @@ static void CompositeClassPartInitialize(widgetClass) </literallayout> </para> <para> -<!-- .LP --> + Nonprocedure fields may be inherited in the same manner as procedure fields. The class may declare any reserved value it wishes for the inheritance constant for its new fields. The following inheritance constants are defined: </para> <para> -<!-- .LP --> + For Object: </para> <itemizedlist> @@ -3206,7 +2841,7 @@ For Object: </listitem> </itemizedlist> <para> -<!-- .LP --> + For Core: </para> <itemizedlist> @@ -3252,7 +2887,7 @@ For Core: </listitem> </itemizedlist> <para> -<!-- .LP --> + For Composite: </para> <itemizedlist> @@ -3278,7 +2913,7 @@ For Composite: </listitem> </itemizedlist> <para> -<!-- .LP --> + For Shell: </para> <itemizedlist> @@ -3296,7 +2931,7 @@ For Shell: <!-- (SN Invocation of Superclass Operations --> <!-- .XE --> <para> -<!-- .LP --> + A widget sometimes needs to call a superclass operation that is not chained. For example, @@ -3311,7 +2946,7 @@ and then calling to add the child to the managed set. </para> <para> -<!-- .LP --> + <!-- .NT --> A class method should not use <function>XtSuperclass</function> @@ -3333,7 +2968,7 @@ This technique is referred to as <emphasis remap='I'>enveloping</emphasis> the s <!-- .XE --> <!-- .IN "Widget" "class extension records" --> <para> -<!-- .LP --> + It may be necessary at times to add new fields to already existing widget class structures. To permit this to be done without requiring recompilation of all subclasses, the last field in a class part structure @@ -3342,7 +2977,7 @@ have yet been defined, subclasses should initialize the value of the extension pointer to NULL. </para> <para> -<!-- .LP --> + If extension fields exist, as is the case with the Composite, Constraint, @@ -3357,7 +2992,7 @@ in the extension record must always check the <emphasis remap='I'>extension</emp some appropriate default action if it is NULL. </para> <para> -<!-- .LP --> + In order to permit multiple subclasses and libraries to chain extension records from a single <emphasis remap='I'>extension</emphasis> field, extension records should be declared as a linked list, and each extension record definition should @@ -3365,7 +3000,7 @@ contain the following four fields at the beginning of the structure declaration: </para> <para> -<!-- .LP --> + <!-- .sM --> <literallayout class="monospaced"> <!-- .TA .5i 3i --> @@ -3424,7 +3059,7 @@ extension record. </variablelist> </para> <para> -<!-- .LP --> + <!-- .eM --> The <emphasis remap='I'>record_type</emphasis> field identifies the contents of the extension record and is used by the definer of the record to locate its particular @@ -3442,7 +3077,7 @@ part extension field to identify the extension record unique to that particular class. </para> <para> -<!-- .LP --> + The <emphasis remap='I'>version</emphasis> field is an owner-defined constant that may be used to identify binary files that have been compiled with alternate definitions of the remainder of the extension record data structure. The private @@ -3453,7 +3088,7 @@ should normally be initialized with <function>sizeof ().</function> </para> <para> -<!-- .LP --> + Any value stored in the class part extension fields of <function>CompositeClassPart ,</function> <function>ConstraintClassPart ,</function> @@ -3462,19 +3097,19 @@ or must point to an extension record conforming to this definition. </para> <para> -<!-- .LP --> + The (xI provide a utility function for widget writers to locate a particular class extension record in a linked list, given a widget class and the offset of the <emphasis remap='I'>extension</emphasis> field in the class record. </para> <para> -<!-- .LP --> + To locate a class extension record, use <function>XtGetClassExtension .</function> <!-- .IN "XtGetClassExtension" "" "@DEF@" --> </para> <para> -<!-- .LP --> + <!-- .sM --> </para> <!-- .FD 0 --> @@ -3547,7 +3182,7 @@ extension record required for a match, or 0. </varlistentry> </variablelist> <para> -<!-- .LP --> + <!-- .eM --> The list of extension records at the specified offset in the specified object class will be searched for a match on the specified type, |