head	1.9;
access;
symbols
	core-8-5-9:1.8
	core-8-5-8:1.8
	macosx-cocoa-merge:1.9
	macosx-cocoa-premerge:1.9
	macosx-carbon-freeze:1.9
	core-8-5-7:1.8
	core-8-5-6:1.8
	core-8-6-b1:1.9
	core-8-6-a3:1.9
	core-8-5-5:1.8
	core-8-6-a2:1.9
	core-8-5-4:1.8
	core-8-5-3:1.8
	core-8-6-a1:1.8
	core-8-4-19:1.4
	core-8-5-branch:1.8.0.2
	core-8-5-2:1.8
	core-8-4-18:1.4
	core-8-5-1:1.8
	core-8-4-17:1.4
	core-8-5-0:1.8
	core-8-5-b3:1.7
	core-8-5-b2:1.6
	core-8-4-16:1.4
	core-8-5-b1:1.6
	core-stablilizer-merge:1.6
	core-stabilizer-branch:1.6.0.2
	core-stabilizer-merge:1.8
	core-8-4-15:1.4
	core-8-5-a6:1.6
	core-8-5-a5:1.5
	core-8-4-14:1.4
	core-8-5-a4:1.5
	core-8-4-13:1.4
	core-8-4-12:1.4
	core-8-4-11:1.4
	core-8-5-a3:1.5
	core-8-4-10:1.4
	core-8-4-9-branch:1.4.0.6
	core-8-5-a2:1.4
	core-8-4-9:1.4
	core-8-4-8:1.4
	core-8-4-7:1.4
	core-8-5-a1:1.4
	core-8-4-6:1.4
	core-8-4-5:1.4
	mistachkin-dev-branch:1.4.0.4
	core-8-4-4:1.4
	core-8-4-3:1.4
	core-8-4-branch:1.4.0.2
	core-8-4-2:1.4
	core-8-4-1:1.4
	core-8-3-5:1.3
	core-8-4-0:1.4
	macosx-8-4-merge-2002-08-31-trunk:1.4
	macosx-8-4-premerge-2002-08-31-branch:1.3.18.1
	macosx-8-4-premerge-2002-08-31-trunk:1.4
	macosx-8-4-merge-2002-08-30-branch:1.3.18.1
	macosx-8-4-merge-2002-08-30-trunk:1.4
	macosx-8-4-merge-2002-08-20-branch:1.3.18.1
	macosx-8-4-merge-2002-08-20-trunk:1.4
	core-8-4-b2:1.4
	core-8-4-b1:1.3
	macosx-premerge-6-9-02:1.3
	core-8-4-a4:1.3
	core-8-3-4:1.3
	macosx-8-4-branch:1.3.0.18
	macosx-8-4-branchpoint:1.3
	core-8-4-a3:1.3
	core-8-3-3:1.3
	dgp-privates-into-namespace:1.3.0.16
	tclpro-1-5-0:1.3
	core-8-4-win-speedup:1.3.0.14
	core-8-4-a2:1.3
	tclpro-1-4-1:1.3
	tclpro-1-4-0:1.3
	core-8-3-2:1.3
	ajuba-ajuba2-2-1-base:1.3
	ajuba-ajuba2-2-0:1.3
	core-8-4-a1:1.3
	core-8-3-1-branch:1.3.0.12
	core-8-3-1:1.3
	scriptics-sc-2-0-b5:1.3
	scriptics-sc-2-0-fixed:1.3
	scriptics-sc-2-0-b2:1.3
	scriptics-sc-2-0-b1:1.3
	core-8-3-0:1.3
	core-8-3-b2:1.3
	core-8-3-b1:1.3
	scriptics-sc-1-1:1.3
	scriptics-sc-1-1-b1:1.3
	core-8-2-3:1.3
	scriptics-sc-1-1-branch:1.3.0.10
	scriptics-sc-1-1-base:1.3
	scriptics-sc-1-0:1.3
	scriptics-sc-1-0-branch:1.3.0.8
	scriptics-sc-1-0-base:1.3
	core-8-2-2:1.3
	core-8-2-1:1.3
	scriptics-bc-1-0-b1:1.3
	core-8-2-1-branch:1.3.0.6
	scriptics-tclpro-1-3-0:1.3
	core-8-2-0:1.3
	core-8-2-b3-branch:1.3.0.4
	core-8-2-b3-base:1.3
	scriptics-tclpro-1-3-b4:1.3
	core-8-2-b2:1.3
	scriptics-tclpro-1-3-b3:1.3
	core-8-2-b1:1.3
	scriptics-tclpro-1-3-b2:1.3
	merge-to-mainline-5/21/99:1.3
	scriptics-tclpro-1-3-b2-branch:1.3.0.2
	core-8-1-1:1.3
	scriptics-tclpro-1-3-b1:1.3
	core-8-1-1-base:1.3
	core-8-1-0:1.3
	merge-to-mainline-4-29-99:1.3
	merge-to-mainline-4-23-99:1.3
	core-8-1-branch-old:1.1.0.4
	core-8-0-6-branch:1.2.0.6
	core-8-0-6-base:1.2
	core-8-0-5:1.2
	core-8-1-b3:1.1.4.2
	core-8-1-b2:1.1.4.2
	dev-8-1-stubs-branch:1.1.4.2.0.2
	dev-stubs-branch:1.2.0.4
	scriptics-tclpro-1-2:1.2
	scriptics-tclpro-1-2-b2:1.2
	core-8-1-merge-2/10/99:1.2
	core-8-0-5-branch:1.2.0.2
	core-8-0-5-base:1.2
	scriptics-tclpro-1-2-b1:1.2
	scriptics-tclpro-1-2-a1:1.2
	core-8-1-b1:1.1.4.2
	core-8-0-4:1.2
	core-8-1-a2:1.1.4.1
	core-8-0-2:1.1
	core-8-0-3:1.2;
locks; strict;
comment	@# @;


1.9
date	2008.06.30.22.57.01;	author dkf;	state Exp;
branches;
next	1.8;

1.8
date	2007.12.13.15.23.43;	author dgp;	state Exp;
branches;
next	1.7;

1.7
date	2007.10.29.16.04.12;	author dkf;	state Exp;
branches;
next	1.6;

1.6
date	2007.01.05.00.00.48;	author nijtmans;	state Exp;
branches
	1.6.2.1;
next	1.5;

1.5
date	2005.04.06.21.11.54;	author dkf;	state Exp;
branches;
next	1.4;

1.4
date	2002.08.05.04.30.38;	author dgp;	state Exp;
branches;
next	1.3;

1.3
date	99.04.16.01.51.08;	author stanton;	state Exp;
branches
	1.3.18.1;
next	1.2;

1.2
date	98.09.14.18.22.48;	author stanton;	state Exp;
branches;
next	1.1;

1.1
date	98.04.01.09.40.04;	author rjohnson;	state Exp;
branches
	1.1.4.1;
next	;

1.1.4.1
date	98.09.29.00.25.08;	author stanton;	state Exp;
branches;
next	1.1.4.2;

1.1.4.2
date	98.09.30.02.15.54;	author stanton;	state Exp;
branches;
next	;

1.3.18.1
date	2002.08.20.20.27.00;	author das;	state Exp;
branches;
next	;

1.6.2.1
date	2007.11.01.16.37.12;	author dgp;	state Exp;
branches;
next	;


desc
@@


1.9
log
@Minor doc updates (removing out of date changebars, improving typedef formatting,
 etc.)
@
text
@'\"
'\" Copyright (c) 1990-1991 The Regents of the University of California.
'\" Copyright (c) 1994-1998 Sun Microsystems, Inc.
'\"
'\" See the file "license.terms" for information on usage and redistribution
'\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
'\" 
'\" RCS: @@(#) $Id: GetColor.3,v 1.8 2007/12/13 15:23:43 dgp Exp $
'\" 
.so man.macros
.TH Tk_AllocColorFromObj 3 8.1 Tk "Tk Library Procedures"
.BS
.SH NAME
Tk_AllocColorFromObj, Tk_GetColor, Tk_GetColorFromObj, Tk_GetColorByValue, Tk_NameOfColor, Tk_FreeColorFromObj, Tk_FreeColor \- maintain database of colors
.SH SYNOPSIS
.nf
\fB#include <tk.h>\fR
.sp
XColor *
\fBTk_AllocColorFromObj(\fIinterp, tkwin, objPtr\fB)\fR
.sp
XColor *
\fBTk_GetColor(\fIinterp, tkwin, name\fB)\fR
.sp
XColor *
\fBTk_GetColorFromObj(\fItkwin, objPtr\fB)\fR
.sp
XColor *
\fBTk_GetColorByValue(\fItkwin, prefPtr\fB)\fR
.sp
const char *
\fBTk_NameOfColor(\fIcolorPtr\fB)\fR
.sp
GC
\fBTk_GCForColor(\fIcolorPtr, drawable\fB)\fR
.sp
\fBTk_FreeColorFromObj(\fItkwin, objPtr\fB)\fR
.sp
\fBTk_FreeColor(\fIcolorPtr\fB)\fR
.SH ARGUMENTS
.AS "Tcl_Interp" *colorPtr
.AP Tcl_Interp *interp in
Interpreter to use for error reporting.
.AP Tk_Window tkwin in
Token for window in which color will be used.
.AP Tcl_Obj *objPtr in/out
String value describes desired color; internal rep will be
modified to cache pointer to corresponding (XColor *).
.AP char *name in
Same as \fIobjPtr\fR except description of color is passed as a string and
resulting (XColor *) is not cached.
.AP XColor *prefPtr in
Indicates red, green, and blue intensities of desired
color.
.AP XColor *colorPtr in
Pointer to X color information.  Must have been allocated by previous
call to \fBTk_AllocColorFromObj\fR, \fBTk_GetColor\fR or
\fBTk_GetColorByValue\fR, except when passed to \fBTk_NameOfColor\fR.
.AP Drawable drawable in
Drawable in which the result graphics context will be used.  Must have
same screen and depth as the window for which the color was allocated.
.BE
.SH DESCRIPTION
.PP
These procedures manage the colors being used by a Tk application.
They allow colors to be shared whenever possible, so that colormap
space is preserved, and they pick closest available colors when
colormap space is exhausted.
.PP
Given a textual description of a color, \fBTk_AllocColorFromObj\fR
locates a pixel value that may be used to render the color
in a particular window.  The desired color is specified with an
object whose string value must have one of the following forms:
.TP 20
\fIcolorname\fR
Any of the valid textual names for a color defined in the
server's color database file, such as \fBred\fR or \fBPeachPuff\fR.
.TP 20
\fB#\fIRGB\fR
.TP 20
\fB#\fIRRGGBB\fR
.TP 20
\fB#\fIRRRGGGBBB\fR
.TP 20
\fB#\fIRRRRGGGGBBBB\fR
A numeric specification of the red, green, and blue intensities
to use to display the color.  Each \fIR\fR, \fIG\fR, or \fIB\fR
represents a single hexadecimal digit.  The four forms permit
colors to be specified with 4-bit, 8-bit, 12-bit or 16-bit values.
When fewer than 16 bits are provided for each color, they represent
the most significant bits of the color.  For example, #3a7 is the
same as #3000a0007000.
.PP
\fBTk_AllocColorFromObj\fR returns a pointer to
an XColor structure;  the structure indicates the exact intensities of
the allocated color (which may differ slightly from those requested,
depending on the limitations of the screen) and a pixel value
that may be used to draw with the color in \fItkwin\fR.
If an error occurs in \fBTk_AllocColorFromObj\fR (such as an unknown
color name) then NULL is returned and an error message is stored in
\fIinterp\fR's result if \fIinterp\fR is not NULL.
If the colormap for \fItkwin\fR is full, \fBTk_AllocColorFromObj\fR
will use the closest existing color in the colormap.
\fBTk_AllocColorFromObj\fR caches information about
the return value in \fIobjPtr\fR, which speeds up future calls to procedures
such as \fBTk_AllocColorFromObj\fR and \fBTk_GetColorFromObj\fR.
.PP
\fBTk_GetColor\fR is identical to \fBTk_AllocColorFromObj\fR except
that the description of the color is specified with a string instead
of an object.  This prevents \fBTk_GetColor\fR from caching the
return value, so \fBTk_GetColor\fR is less efficient than
\fBTk_AllocColorFromObj\fR.
.PP
\fBTk_GetColorFromObj\fR returns the token for an existing color, given
the window and description used to create the color.
\fBTk_GetColorFromObj\fR does not actually create the color; the color
must already have been created with a previous call to
\fBTk_AllocColorFromObj\fR or \fBTk_GetColor\fR.  The return
value is cached in \fIobjPtr\fR, which speeds up
future calls to \fBTk_GetColorFromObj\fR with the same \fIobjPtr\fR
and \fItkwin\fR.
.PP
\fBTk_GetColorByValue\fR is similar to \fBTk_GetColor\fR except that
the desired color is indicated with the \fIred\fR, \fIgreen\fR, and
\fIblue\fR fields of the structure pointed to by \fIcolorPtr\fR.
.PP
This package maintains a database
of all the colors currently in use.
If the same color is requested multiple times from
\fBTk_GetColor\fR or \fBTk_AllocColorFromObj\fR (e.g. by different
windows), or if the 
same intensities are requested multiple times from
\fBTk_GetColorByValue\fR, then existing pixel values will
be re-used.  Re-using an existing pixel avoids any interaction
with the window server, which makes the allocation much more
efficient.  These procedures also provide a portable interface that
works across all platforms.  For this reason, you should generally use
\fBTk_AllocColorFromObj\fR, \fBTk_GetColor\fR, or \fBTk_GetColorByValue\fR
instead of lower level procedures like \fBXAllocColor\fR.
.PP
Since different calls to this package
may return the same shared
pixel value, callers should never change the color of a pixel
returned by the procedures.
If you need to change a color value dynamically, you should use
\fBXAllocColorCells\fR to allocate the pixel value for the color.
.PP
The procedure \fBTk_NameOfColor\fR is roughly the inverse of
\fBTk_GetColor\fR.  If its \fIcolorPtr\fR argument was created
by \fBTk_AllocColorFromObj\fR or \fBTk_GetColor\fR then the return value
is the string that was used to create the
color.  If \fIcolorPtr\fR was created by a call to \fBTk_GetColorByValue\fR,
or by any other mechanism, then the return value is a string
that could be passed to \fBTk_GetColor\fR to return the same
color.  Note:  the string returned by \fBTk_NameOfColor\fR is
only guaranteed to persist until the next call to
\fBTk_NameOfColor\fR.
.PP
\fBTk_GCForColor\fR returns a graphics context whose \fBforeground\fR
field is the pixel allocated for \fIcolorPtr\fR and whose other fields
all have default values.
This provides an easy way to do basic drawing with a color.
The graphics context is cached with the color and will exist only as
long as \fIcolorPtr\fR exists;  it is freed when the last reference
to \fIcolorPtr\fR is freed by calling \fBTk_FreeColor\fR.
.PP
When a color is no longer needed \fBTk_FreeColorFromObj\fR or
\fBTk_FreeColor\fR should be called to release it.
For \fBTk_FreeColorFromObj\fR the color to release is specified
with the same information used to create it; for
\fBTk_FreeColor\fR the color to release is specified
with a pointer to its XColor structure.
There should be exactly one call to \fBTk_FreeColorFromObj\fR
or \fBTk_FreeColor\fR for each call to \fBTk_AllocColorFromObj\fR,
\fBTk_GetColor\fR, or \fBTk_GetColorByValue\fR.
.SH KEYWORDS
color, intensity, object, pixel value
@


1.8
log
@merge stable branch onto HEAD
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: GetColor.3,v 1.6.2.1 2007/11/01 16:37:12 dgp Exp $
a62 1

@


1.7
log
@Lots more GOOBE stuff. Now works with 'make html'!
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: GetColor.3,v 1.6 2007/01/05 00:00:48 nijtmans Exp $
@


1.6
log
@various "const" additions, in line with TIP #27
fix bug #1627732
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: GetColor.3,v 1.5 2005/04/06 21:11:54 dkf Exp $
d51 1
a51 1
resulting (XColor *) isn't cached.
d102 1
a102 1
\fIinterp\fR's result if \fIinterp\fR isn't NULL.
d117 1
a117 1
\fBTk_GetColorFromObj\fR doesn't actually create the color; the color
@


1.6.2.1
log
@merge updates from HEAD
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: GetColor.3,v 1.6 2007/01/05 00:00:48 nijtmans Exp $
d51 1
a51 1
resulting (XColor *) is not cached.
d102 1
a102 1
\fIinterp\fR's result if \fIinterp\fR is not NULL.
d117 1
a117 1
\fBTk_GetColorFromObj\fR does not actually create the color; the color
@


1.5
log
@Purge old and inaccurate .VS/.VE macros.
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: GetColor.3,v 1.4 2002/08/05 04:30:38 dgp Exp $
d31 1
a31 1
CONST char *
@


1.4
log
@Applied companion patch for Tcl Patch 585105,
updating Tk to use Tcl 8.4's fully CONST-ified
interface, and fully CONSTifying Tk at the
same time.

This patch includes purging Tk of its last
direct access to interp->result.  [Bug 589853]

The substantial changes include copying
event sequence strings into Tcl_DStrings
in tkBind.c, and copying [text] indices into
Tcl_DStrings because parsing them involved
overwriting them.  If this causes performance
trouble, that can be resolved by further
converting them to Tcl_Obj's.

The #defines USE_NON_CONST and USE_COMPAT_CONST
have the same effect for Tk as they do for Tcl.
(They actually change tcl.h)
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: GetColor.3,v 1.3 1999/04/16 01:51:08 stanton Exp $
a17 1
.VS 8.1
a26 1
.VE
a36 1
.VS 8.1
a37 1
.VE
a45 1
.VS 8.1 br
a51 1
.VE
a64 1
.VS 8.1
a74 1
.VE
a94 1
.VS 8.1
a122 1
.VE
a167 1
.VS 8.1
a176 1
.VE
@


1.3
log
@* Merged 8.1 branch into the main trunk
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id$
d33 1
a33 1
char *
@


1.3.18.1
log
@merged with trunk at tag macosx-8-4-merge-2002-08-20-trunk
@
text
@d33 1
a33 1
CONST char *
@


1.2
log
@Replaced SCCS strings, fixed binary files
@
text
@d2 2
a3 2
'\" Copyright (c) 1990, 1991 The Regents of the University of California.
'\" Copyright (c) 1994-1996 Sun Microsystems, Inc.
d11 1
a11 1
.TH Tk_GetColor 3 4.0 Tk "Tk Library Procedures"
d14 1
a14 1
Tk_GetColor, Tk_GetColorByValue, Tk_NameOfColor, Tk_FreeColor \- maintain database of colors
d18 1
d21 1
a21 1
\fBTk_GetColor\fR(\fIinterp, tkwin, nameId\fB)\fR
d24 8
a31 1
\fBTk_GetColorByValue\fR(\fItkwin, prefPtr\fB)\fR
d37 5
a41 1
\fBTk_GCForColor\fR(\fIcolorPtr, drawable\fR)
d50 8
a57 2
.AP Tk_Uid nameId in
Textual description of desired color.
d63 2
a64 2
call to \fBTk_GetColor\fR or \fBTk_GetColorByValue\fR, except when passed
to \fBTk_NameOfColor\fR.
d71 1
d73 10
a82 5
The \fBTk_GetColor\fR and \fBTk_GetColorByValue\fR procedures
locate pixel values that may be used to render particular
colors in the window given by \fItkwin\fR.  In \fBTk_GetColor\fR
the desired color is specified with a Tk_Uid (\fInameId\fR), which
may have any of the following forms:
d103 2
a104 6
In \fBTk_GetColorByValue\fR, the desired color is indicated with
the \fIred\fR, \fIgreen\fR, and \fIblue\fR fields of the structure
pointed to by \fIcolorPtr\fR.
.PP
If \fBTk_GetColor\fR or \fBTk_GetColorByValue\fR is successful
in allocating the desired color, then it returns a pointer to
d108 29
a136 8
that may be used to draw in the color.
If the colormap for \fItkwin\fR is full, \fBTk_GetColor\fR
and \fBTk_GetColorByValue\fR will use the closest existing color
in the colormap.
If \fBTk_GetColor\fR encounters an error while allocating
the color (such as an unknown color name) then NULL is returned and
an error message is stored in \fIinterp->result\fR;
\fBTk_GetColorByValue\fR never returns an error.
d138 1
a138 1
\fBTk_GetColor\fR and \fBTk_GetColorByValue\fR maintain a database
d140 3
a142 2
If the same \fInameId\fR is requested multiple times from
\fBTk_GetColor\fR (e.g. by different windows), or if the
d146 5
a150 5
with the X server, which makes the allocation much more
efficient.  For this reason, you should generally use
\fBTk_GetColor\fR or \fBTk_GetColorByValue\fR
instead of Xlib procedures like \fBXAllocColor\fR,
\fBXAllocNamedColor\fR, or \fBXParseColor\fR.
d152 1
a152 1
Since different calls to \fBTk_GetColor\fR or \fBTk_GetColorByValue\fR
d161 2
a162 2
by \fBTk_GetColor\fR, then the return value is the \fInameId\fR
string that was passed to \fBTk_GetColor\fR to create the
d167 2
a168 1
only guaranteed to persist until the next call to \fBTk_NameOfColor\fR.
d170 1
a170 1
\fBTk_GCForColor\fR returns a graphics context whose \fBForeground\fR
d178 11
a188 10
When a pixel value returned by \fBTk_GetColor\fR or
\fBTk_GetColorByValue\fR is no longer
needed, \fBTk_FreeColor\fR should be called to release the color.
There should be exactly one call to \fBTk_FreeColor\fR for
each call to \fBTk_GetColor\fR or \fBTk_GetColorByValue\fR.
When a pixel value is no longer in
use anywhere (i.e. it has been freed as many times as it has been gotten)
\fBTk_FreeColor\fR will release it to the X server and delete it from
the database.

d190 1
a190 1
color, intensity, pixel value
@


1.1
log
@Initial revision
@
text
@d8 1
a8 1
'\" SCCS: @@(#) GetColor.3 1.22 96/08/27 13:21:26
@


1.1.4.1
log
@initial tk8.1a2 version
@
text
@d2 2
a3 2
'\" Copyright (c) 1990-1991 The Regents of the University of California.
'\" Copyright (c) 1994-1998 Sun Microsystems, Inc.
d8 1
a8 1
'\" SCCS: @@(#) GetColor.3 1.24 98/01/14 13:58:58
d11 1
a11 1
.TH Tk_AllocColorFromObj 3 8.1 Tk "Tk Library Procedures"
d14 1
a14 1
Tk_AllocColorFromObj, Tk_GetColor, Tk_GetColorFromObj, Tk_GetColorByValue, Tk_NameOfColor, Tk_FreeColorFromObj, Tk_FreeColor \- maintain database of colors
a17 1
.VS 8.1
d20 1
a20 1
\fBTk_AllocColorFromObj(\fIinterp, tkwin, objPtr\fB)\fR
d23 1
a23 8
\fBTk_GetColor(\fIinterp, tkwin, name\fB)\fR
.sp
XColor *
\fBTk_GetColorFromObj(\fItkwin, objPtr\fB)\fR
.VE
.sp
XColor *
\fBTk_GetColorByValue(\fItkwin, prefPtr\fB)\fR
d29 1
a29 5
\fBTk_GCForColor(\fIcolorPtr, drawable\fB)\fR
.sp
.VS 8.1
\fBTk_FreeColorFromObj(\fItkwin, objPtr\fB)\fR
.VE
d38 2
a39 8
.VS 8.1 br
.AP Tcl_Obj *objPtr in/out
String value describes desired color; internal rep will be
modified to cache pointer to corresponding (XColor *).
.AP char *name in
Same as \fIobjPtr\fR except description of color is passed as a string and
resulting (XColor *) isn't cached.
.VE
d45 2
a46 2
call to \fBTk_AllocColorFromObj\fR, \fBTk_GetColor\fR or
\fBTk_GetColorByValue\fR, except when passed to \fBTk_NameOfColor\fR.
a52 1
.VS 8.1
d54 5
a58 10
These procedures manage the colors being used by a Tk application.
They allow colors to be shared whenever possible, so that colormap
space is preserved, and they pick closest available colors when
colormap space is exhausted.
.PP
Given a textual description of a color, \fBTk_AllocColorFromObj\fR
locates a pixel value that may be used to render the color
in a particular window.  The desired color is specified with an
object whose string value must have one of the following forms:
.VE
d79 6
a84 2
.VS 8.1
\fBTk_AllocColorFromObj\fR returns a pointer to
d88 8
a95 29
that may be used to draw with the color in \fItkwin\fR.
If an error occurs in \fBTk_AllocColorFromObj\fR (such as an unknown
color name) then NULL is returned and an error message is stored in
\fIinterp\fR's result if \fIinterp\fR isn't NULL.
If the colormap for \fItkwin\fR is full, \fBTk_AllocColorFromObj\fR
will use the closest existing color in the colormap.
\fBTk_AllocColorFromObj\fR caches information about
the return value in \fIobjPtr\fR, which speeds up future calls to procedures
such as \fBTk_AllocColorFromObj\fR and \fBTk_GetColorFromObj\fR.
.PP
\fBTk_GetColor\fR is identical to \fBTk_AllocColorFromObj\fR except
that the description of the color is specified with a string instead
of an object.  This prevents \fBTk_GetColor\fR from caching the
return value, so \fBTk_GetColor\fR is less efficient than
\fBTk_AllocColorFromObj\fR.
.PP
\fBTk_GetColorFromObj\fR returns the token for an existing color, given
the window and description used to create the color.
\fBTk_GetColorFromObj\fR doesn't actually create the color; the color
must already have been created with a previous call to
\fBTk_AllocColorFromObj\fR or \fBTk_GetColor\fR.  The return
value is cached in \fIobjPtr\fR, which speeds up
future calls to \fBTk_GetColorFromObj\fR with the same \fIobjPtr\fR
and \fItkwin\fR.
.VE
.PP
\fBTk_GetColorByValue\fR is similar to \fBTk_GetColor\fR except that
the desired color is indicated with the \fIred\fR, \fIgreen\fR, and
\fIblue\fR fields of the structure pointed to by \fIcolorPtr\fR.
d97 1
a97 1
This package maintains a database
d99 2
a100 3
If the same color is requested multiple times from
\fBTk_GetColor\fR or \fBTk_AllocColorFromObj\fR (e.g. by different
windows), or if the 
d104 5
a108 5
with the window server, which makes the allocation much more
efficient.  These procedures also provide a portable interface that
works across all platforms.  For this reason, you should generally use
\fBTk_AllocColorFromObj\fR, \fBTk_GetColor\fR, or \fBTk_GetColorByValue\fR
instead of lower level procedures like \fBXAllocColor\fR.
d110 1
a110 1
Since different calls to this package
d119 2
a120 2
by \fBTk_AllocColorFromObj\fR or \fBTk_GetColor\fR then the return value
is the string that was used to create the
d125 1
a125 2
only guaranteed to persist until the next call to
\fBTk_NameOfColor\fR.
d127 1
a127 1
\fBTk_GCForColor\fR returns a graphics context whose \fBforeground\fR
d135 10
a144 11
.VS 8.1
When a color is no longer needed \fBTk_FreeColorFromObj\fR or
\fBTk_FreeColor\fR should be called to release it.
For \fBTk_FreeColorFromObj\fR the color to release is specified
with the same information used to create it; for
\fBTk_FreeColor\fR the color to release is specified
with a pointer to its XColor structure.
There should be exactly one call to \fBTk_FreeColorFromObj\fR
or \fBTk_FreeColor\fR for each call to \fBTk_AllocColorFromObj\fR,
\fBTk_GetColor\fR, or \fBTk_GetColorByValue\fR.
.VE
d146 1
a146 1
color, intensity, object, pixel value
@


1.1.4.2
log
@Merged 8.0.3 changes into 8.1
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: GetColor.3,v 1.2 1998/09/14 18:22:48 stanton Exp $
@


