DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - download
Index: ┃ T c

⟦a9ca2de54⟧ TextFile

    Length: 4111 (0x100f)
    Types: TextFile
    Names: »ch12b.t«

Derivation

└─⟦a0efdde77⟧ Bits:30001252 EUUGD11 Tape, 1987 Spring Conference Helsinki
    └─ ⟦526ad3590⟧ »EUUGD11/gnu-31mar87/X.V10.R4.tar.Z« 
        └─⟦2109abc41⟧ 
            └─ ⟦this⟧ »./X.V10R4/doc/Xlib/ch12b.t« 

TextFile

.NH 2
Associating X Resources to User Data Structures
.IN "Hash Lookup"
.IN "Window" "ID's"
.IN "Resource ID's"
.IN "XId"
.PP
Application programs often need to be able to easily refer to
their own data structures when an event arrives.
The \fIXAssocTable\fP system provides users of the X library with  a  method
of associating their own data structures with X resources.
(Bitmaps, Pixmaps, Fonts, Windows, and so on).
.PP
An  \fIXAssocTable\fP can be used to type X resources.  
For example, the user
may wish to have three or four `types' of windows each with  different
properties. 
This can be accomplished by associating each X window id
with a pointer to a `window property' data structure  defined  by  the
user.
.IN "Definitions" "XId"
A generic type has been defined in the X library for resource id's.
.IN "XId"
It is called ``XId''.
.PP
There  are  a  few  guidelines  that  should be observed when using an
\fIXAssocTable\fP:
.LP
.IN "XId"
First, all  \fIXId\fP's  are  relative  to  the  currently  active  display.
Therefore,  if you are using multiple displays you need to be sure the
correct display is active before performing an \fIXAssocTable\fP operation.
\fIXAssocTable\fP  imposes no restrictions on the number of X ids per table,
the number of X ids per display or the number of displays per table.
.LP
Second,  because  of  the  hashing  scheme  used  by  the  association
mechanism the following rules for determining the size of \fIXAssocTable\fPs
should be followed.  
Associations will be  made  and  looked  up  more
efficiently  if  the  table  size  (number  of  buckets in the hashing
system) is a power of two and if there are not more than 8 Xids  per
bucket.
.FD
.IN "XAssocTable"
.IN "Definitions" "XCreateAssocTable"
.IN "XCreateAssocTable"
XAssocTable *XCreateAssocTable(size)
	int size;	/* Desired size (in buckets) of the table. */
.FN
This routine returns a pointer to a newly created \fIXAssocTable\fP.
The "size" argument specifies the number of buckets  in  \fIXAssocTable\fP's
hashing  system.   For  reasons  of  efficiency  the number of buckets
should be a power of two.  Some size  suggestions  might  be:  use  32
buckets  per  100  objects;  a reasonable maximum number of object per
buckets is 8.   If  there  is  an  error  allocating  memory  for  the
\fIXAssocTable\fP, a NULL pointer is returned. 
.FD
.IN "XAssocTable"
.IN "Definitions" "XDestroyAssocTable"
.IN "XDestroyAssocTable"
XDestroyAssocTable(table)
	XAssocTable *table;	/* Table to destroy. */
.FN
Destroy (free the  memory  associated  with)  an  XAssocTable.
Using an \fIXAssocTable\fP after it has been destroyed is guaranteed to have
unpredictable and probably disastrous consequences!
.FD
.IN "XAssocTable"
.IN "Definitions" "XMakeAssoc"
.IN "XMakeAssoc"
XMakeAssoc(table, x_id, data)
	XAssocTable *table;	/* Table in which to make the association. */
	XId x_id;	/* X resource id. */
	caddr_t data;	/* Data to associate with the XId. */
.FN
.IN "XId"
Insert data into an \fIXAssocTable\fP keyed  on  an  XId.   Data  is
inserted  into the table only once.  Redundant inserts are meaningless
and cause no problems.  The queue in each association bucket is sorted
from the lowest XId to the highest XId.
.FD
.IN "XAssocTable"
.IN "Definitions" "XLookUpAssoc"
.IN "XLookupAssoc"
caddr_t XLookUpAssoc(table, x_id)
	XAssocTable *table;	/* Table to look in. */
	XId x_id;	/* XId to look for. */
.FN
.IN "XId"
Retrieve the data stored in an \fIXAssocTable\fP by its XId.  If  an
appropriately  matching XId can be found in the table the routine will
return the data associated with it. If the \fIx_id\fP can not be found in the
table the routine will return NULL.
.FD
.IN "XAssocTable"
.IN "Definitions" "XDeleteAssoc"
.IN "XDeleteAssoc"
XDeleteAssoc(table, x_id)
	XAssocTable *table;	/* Table to look in. */
	XId x_id;	/* XId to delete. */
.FN
.IN "XId"
Delete an association in an \fIXAssocTable\fP keyed on its XId.
Redundant deletes (and deletes of non-existant XId's) are meaningless
and cause no problems.  Deleteing associations in no way impares
the performance of an \fIXAssocTable\fP.