head	1.16;
access;
symbols
	core-8-5-9:1.13
	core-8-5-8:1.13
	macosx-cocoa-merge:1.16
	macosx-cocoa-premerge:1.16
	macosx-carbon-freeze:1.16
	core-8-5-7:1.13
	core-8-5-6:1.13
	core-8-6-b1:1.16
	core-8-6-a3:1.14
	core-8-5-5:1.13
	core-8-6-a2:1.14
	core-8-5-4:1.13
	core-8-5-3:1.13
	core-8-6-a1:1.13
	core-8-4-19:1.6.2.1
	core-8-5-branch:1.13.0.2
	core-8-5-2:1.13
	core-8-4-18:1.6.2.1
	core-8-5-1:1.13
	core-8-4-17:1.6.2.1
	core-8-5-0:1.13
	core-8-5-b3:1.11
	core-8-5-b2:1.11
	core-8-4-16:1.6.2.1
	core-8-5-b1:1.11
	core-stablilizer-merge:1.11
	core-stabilizer-branch:1.11.0.2
	core-stabilizer-merge:1.13
	core-8-4-15:1.6.2.1
	core-8-5-a6:1.10
	core-8-5-a5:1.9
	core-8-4-14:1.6.2.1
	core-8-5-a4:1.9
	core-8-4-13:1.6.2.1
	core-8-4-12:1.6.2.1
	core-8-4-11:1.6.2.1
	core-8-5-a3:1.9
	core-8-4-10:1.6.2.1
	core-8-4-9-branch:1.6.2.1.0.2
	core-8-5-a2:1.8
	core-8-4-9:1.6.2.1
	core-8-4-8:1.6.2.1
	core-8-4-7:1.6.2.1
	core-8-5-a1:1.7
	core-8-4-6:1.6.2.1
	core-8-4-5:1.6
	mistachkin-dev-branch:1.6.0.4
	core-8-4-4:1.6
	core-8-4-3:1.6
	core-8-4-branch:1.6.0.2
	core-8-4-2:1.6
	core-8-4-1:1.6
	core-8-3-5:1.4.2.1
	core-8-4-0:1.6
	macosx-8-4-merge-2002-08-31-trunk:1.6
	macosx-8-4-premerge-2002-08-31-branch:1.5.6.1
	macosx-8-4-premerge-2002-08-31-trunk:1.6
	macosx-8-4-merge-2002-08-30-branch:1.5.6.1
	macosx-8-4-merge-2002-08-30-trunk:1.6
	macosx-8-4-merge-2002-08-20-branch:1.5.6.1
	macosx-8-4-merge-2002-08-20-trunk:1.6
	core-8-4-b2:1.6
	core-8-4-b1:1.5
	macosx-premerge-6-9-02:1.5
	core-8-4-a4:1.5
	core-8-3-4:1.4.2.1
	macosx-8-4-branch:1.5.0.6
	macosx-8-4-branchpoint:1.5
	core-8-4-a3:1.5
	core-8-3-3:1.4.2.1
	dgp-privates-into-namespace:1.5.0.4
	tclpro-1-5-0:1.4
	core-8-4-win-speedup:1.5.0.2
	core-8-4-a2:1.5
	tclpro-1-4-1:1.4
	tclpro-1-4-0:1.4
	core-8-3-2:1.4
	ajuba-ajuba2-2-1-base:1.4
	ajuba-ajuba2-2-0:1.4
	core-8-4-a1:1.4
	core-8-3-1-branch:1.4.0.2
	core-8-3-1:1.4
	scriptics-sc-2-0-b5:1.4
	scriptics-sc-2-0-fixed:1.4
	scriptics-sc-2-0-b2:1.4
	scriptics-sc-2-0-b1:1.4
	core-8-3-0:1.4
	core-8-3-b2:1.3
	core-8-3-b1:1.3
	scriptics-sc-1-1:1.2
	scriptics-sc-1-1-b1:1.2
	core-8-2-3:1.2
	scriptics-sc-1-1-branch:1.2.0.16
	scriptics-sc-1-1-base:1.2
	scriptics-sc-1-0:1.2
	scriptics-sc-1-0-branch:1.2.0.14
	scriptics-sc-1-0-base:1.2
	core-8-2-2:1.2
	core-8-2-1:1.2
	scriptics-bc-1-0-b1:1.2
	core-8-2-1-branch:1.2.0.12
	scriptics-tclpro-1-3-0:1.2
	core-8-2-0:1.2
	core-8-2-b3-branch:1.2.0.10
	core-8-2-b3-base:1.2
	scriptics-tclpro-1-3-b4:1.2
	core-8-2-b2:1.2
	scriptics-tclpro-1-3-b3:1.2
	core-8-2-b1:1.2
	scriptics-tclpro-1-3-b2:1.2
	merge-to-mainline-5/21/99:1.2
	scriptics-tclpro-1-3-b2-branch:1.2.0.8
	core-8-1-1:1.2
	scriptics-tclpro-1-3-b1:1.2
	core-8-1-1-base:1.2
	core-8-1-0:1.2
	merge-to-mainline-4-29-99:1.2
	merge-to-mainline-4-23-99:1.2
	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.1
	core-8-1-b2:1.1.4.1
	dev-8-1-stubs-branch:1.1.4.1.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.1
	core-8-0-4:1.2
	core-8-1-a2:1.1
	core-8-0-2:1.1
	core-8-0-3:1.2;
locks; strict;
comment	@# @;


1.16
date	2008.11.12.00.15.26;	author nijtmans;	state Exp;
branches;
next	1.15;

1.15
date	2008.11.09.23.16.56;	author nijtmans;	state Exp;
branches;
next	1.14;

1.14
date	2008.06.30.22.57.01;	author dkf;	state Exp;
branches;
next	1.13;

1.13
date	2007.12.13.15.23.42;	author dgp;	state Exp;
branches;
next	1.12;

1.12
date	2007.12.10.16.21.48;	author jenglish;	state Exp;
branches;
next	1.11;

1.11
date	2007.05.14.20.58.25;	author dgp;	state Exp;
branches
	1.11.2.1;
next	1.10;

1.10
date	2007.01.05.00.00.48;	author nijtmans;	state Exp;
branches;
next	1.9;

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

1.8
date	2004.09.19.16.05.36;	author dkf;	state Exp;
branches;
next	1.7;

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

1.6
date	2002.08.05.04.30.38;	author dgp;	state Exp;
branches
	1.6.2.1;
next	1.5;

1.5
date	2000.07.25.21.14.34;	author jenglish;	state Exp;
branches
	1.5.6.1;
next	1.4;

1.4
date	2000.02.08.11.31.30;	author hobbs;	state Exp;
branches
	1.4.2.1;
next	1.3;

1.3
date	99.10.29.03.57.40;	author hobbs;	state Exp;
branches;
next	1.2;

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

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

1.1.4.1
date	98.09.30.02.15.48;	author stanton;	state Exp;
branches;
next	;

1.4.2.1
date	2001.04.04.07.23.48;	author hobbs;	state Exp;
branches;
next	;

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

1.6.2.1
date	2003.12.10.09.40.43;	author dkf;	state Exp;
branches;
next	;

1.11.2.1
date	2007.12.10.18.39.27;	author dgp;	state Exp;
branches;
next	;


desc
@@


1.16
log
@modify Tk_Create(Old)ImageType signature, relaxing
the constraint that every Tk_ImageType can only
be passed to this function once. This allows
tkImg to be loaded in multiple interpreters
in a thread-enabled build of Tk.
This CONSTification complies with TIP #27. It is
binary compatible with the old interface, but not
fully source compatible (although tkImg does not suffer).
@
text
@'\"
'\" Copyright (c) 1994 The Regents of the University of California.
'\" Copyright (c) 1994-1997 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: CrtImgType.3,v 1.15 2008/11/09 23:16:56 nijtmans Exp $
'\" 
.so man.macros
.TH Tk_CreateImageType 3 8.5 Tk "Tk Library Procedures"
.BS
.SH NAME
Tk_CreateImageType, Tk_GetImageMasterData, Tk_InitImageArgs \- define new kind of image
.SH SYNOPSIS
.nf
\fB#include <tk.h>\fR
.sp
\fBTk_CreateImageType\fR(\fItypePtr\fR)
.sp
ClientData
\fBTk_GetImageMasterData\fR(\fIinterp, name, typePtrPtr\fR)
.sp
\fBTk_InitImageArgs\fR(\fIinterp, argc, argvPtr\fR)
.SH ARGUMENTS
.AS "const Tk_ImageType" *typePtrPtr
.AP "const Tk_ImageType" *typePtr in
Structure that defines the new type of image.
For Tk 8.4 and earlier this must be static: a
pointer to this structure is retained by the image code.
In Tk 8.5, this limitation was relaxed.
.AP Tcl_Interp *interp in
Interpreter in which image was created.
.AP "const char" *name in
Name of existing image.
.AP Tk_ImageType **typePtrPtr out
Points to word in which to store a pointer to type information for
the given image, if it exists.
.AP int argc in
Number of arguments
.AP char ***argvPtr in/out
Pointer to argument list
.BE
.SH DESCRIPTION
.PP
\fBTk_CreateImageType\fR is invoked to define a new kind of image.
An image type corresponds to a particular value of the \fItype\fR
argument for the \fBimage create\fR command.  There may exist
any number of different image types, and new types may be defined
dynamically by calling \fBTk_CreateImageType\fR.
For example, there might be one type for 2-color bitmaps,
another for multi-color images, another for dithered images,
another for video, and so on.
.PP
The code that implements a new image type is called an
\fIimage manager\fR.
It consists of a collection of procedures plus three different
kinds of data structures.
The first data structure is a Tk_ImageType structure, which contains
the name of the image type and pointers to five procedures provided
by the image manager to deal with images of this type:
.CS
typedef struct Tk_ImageType {
    const char *\fIname\fR;
    Tk_ImageCreateProc *\fIcreateProc\fR;
    Tk_ImageGetProc *\fIgetProc\fR;
    Tk_ImageDisplayProc *\fIdisplayProc\fR;
    Tk_ImageFreeProc *\fIfreeProc\fR;
    Tk_ImageDeleteProc *\fIdeleteProc\fR;
} \fBTk_ImageType\fR;
.CE
The fields of this structure will be described in later subsections
of this entry.
.PP
The second major data structure manipulated by an image manager
is called an \fIimage master\fR;  it contains overall information
about a particular image, such as the values of the configuration
options specified in an \fBimage create\fR command.
There will usually be one of these structures for each
invocation of the \fBimage create\fR command.
.PP
The third data structure related to images is an \fIimage instance\fR.
There will usually be one of these structures for each usage of an
image in a particular widget.
It is possible for a single image to appear simultaneously
in multiple widgets, or even multiple times in the same widget.
Furthermore, different instances may be on different screens
or displays.
The image instance data structure describes things that may
vary from instance to instance, such as colors and graphics
contexts for redisplay.
There is usually one instance structure for each \fB\-image\fR
option specified for a widget or canvas item.
.PP
The following subsections describe the fields of a Tk_ImageType
in more detail.
.SS NAME
.PP
\fItypePtr->name\fR provides a name for the image type.
Once \fBTk_CreateImageType\fR returns, this name may be used
in \fBimage create\fR commands to create images of the new
type.
If there already existed an image type by this name then
the new image type replaces the old one.
.SS CREATEPROC
.PP
\fItypePtr->createProc\fR provides the address of a procedure for
Tk to call whenever \fBimage create\fR is invoked to create
an image of the new type.
\fItypePtr->createProc\fR must match the following prototype:
.CS
typedef int \fBTk_ImageCreateProc\fR(
        Tcl_Interp *\fIinterp\fR,
        const char *\fIname\fR,
        int \fIobjc\fR,
        Tcl_Obj *const \fIobjv\fR[],
        const Tk_ImageType *\fItypePtr\fR,
        Tk_ImageMaster \fImaster\fR,
        ClientData *\fImasterDataPtr\fR);
.CE
The \fIinterp\fR argument is the interpreter in which the \fBimage\fR
command was invoked, and \fIname\fR is the name for the new image,
which was either specified explicitly in the \fBimage\fR command
or generated automatically by the \fBimage\fR command.
The \fIobjc\fR and \fIobjv\fR arguments describe all the configuration
options for the new image (everything after the name argument to
\fBimage\fR).
The \fImaster\fR argument is a token that refers to Tk's information
about this image;  the image manager must return this token to
Tk when invoking the \fBTk_ImageChanged\fR procedure.
Typically \fIcreateProc\fR will parse \fIobjc\fR and \fIobjv\fR
and create an image master data structure for the new image.
\fIcreateProc\fR may store an arbitrary one-word value at
*\fImasterDataPtr\fR, which will be passed back to the
image manager when other callbacks are invoked.
Typically the value is a pointer to the master data
structure for the image.
.PP
If \fIcreateProc\fR encounters an error, it should leave an error
message in the interpreter result and return \fBTCL_ERROR\fR;  otherwise
it should return \fBTCL_OK\fR.
.PP
\fIcreateProc\fR should call \fBTk_ImageChanged\fR in order to set the
size of the image and request an initial redisplay.
.SS GETPROC
.PP
\fItypePtr->getProc\fR is invoked by Tk whenever a widget
calls \fBTk_GetImage\fR to use a particular image.
This procedure must match the following prototype:
.CS
typedef ClientData \fBTk_ImageGetProc\fR(
        Tk_Window \fItkwin\fR,
        ClientData \fImasterData\fR);
.CE
The \fItkwin\fR argument identifies the window in which the
image will be used and \fImasterData\fR is the value
returned by \fIcreateProc\fR when the image master was created.
\fIgetProc\fR will usually create a data structure for the new
instance, including such things as the resources needed to
display the image in the given window.
\fIgetProc\fR returns a one-word token for the instance, which
is typically the address of the instance data structure.
Tk will pass this value back to the image manager when invoking
its \fIdisplayProc\fR and \fIfreeProc\fR procedures.
.SS DISPLAYPROC
.PP
\fItypePtr->displayProc\fR is invoked by Tk whenever an image needs
to be displayed (i.e., whenever a widget calls \fBTk_RedrawImage\fR).
\fIdisplayProc\fR must match the following prototype:
.CS
typedef void \fBTk_ImageDisplayProc\fR(
        ClientData \fIinstanceData\fR,
        Display *\fIdisplay\fR,
        Drawable \fIdrawable\fR,
        int \fIimageX\fR,
        int \fIimageY\fR,
        int \fIwidth\fR,
        int \fIheight\fR,
        int \fIdrawableX\fR,
        int \fIdrawableY\fR);
.CE
The \fIinstanceData\fR will be the same as the value returned by
\fIgetProc\fR when the instance was created.
\fIdisplay\fR and \fIdrawable\fR indicate where to display the
image;  \fIdrawable\fR may be a pixmap rather than
the window specified to \fIgetProc\fR (this is usually the case,
since most widgets double-buffer their redisplay to get smoother
visual effects).
\fIimageX\fR, \fIimageY\fR, \fIwidth\fR, and \fIheight\fR
identify the region of the image that must be redisplayed.
This region will always be within the size of the image
as specified in the most recent call to \fBTk_ImageChanged\fR.
\fIdrawableX\fR and \fIdrawableY\fR indicate where in \fIdrawable\fR
the image should be displayed;  \fIdisplayProc\fR should display
the given region of the image so that point (\fIimageX\fR, \fIimageY\fR)
in the image appears at (\fIdrawableX\fR, \fIdrawableY\fR) in \fIdrawable\fR.
.SS FREEPROC
.PP
\fItypePtr->freeProc\fR contains the address of a procedure that
Tk will invoke when an image instance is released (i.e., when
\fBTk_FreeImage\fR is invoked).
This can happen, for example, when a widget is deleted or a image item
in a canvas is deleted, or when the image displayed in a widget or
canvas item is changed.
\fIfreeProc\fR must match the following prototype:
.CS
typedef void \fBTk_ImageFreeProc\fR(
        ClientData \fIinstanceData\fR,
        Display *\fIdisplay\fR);
.CE
The \fIinstanceData\fR will be the same as the value returned by
\fIgetProc\fR when the instance was created, and \fIdisplay\fR
is the display containing the window for the instance.
\fIfreeProc\fR should release any resources associated with the
image instance, since the instance will never be used again.
.SS DELETEPROC
.PP
\fItypePtr->deleteProc\fR is a procedure that Tk invokes when an
image is being deleted (i.e. when the \fBimage delete\fR command
is invoked).
Before invoking \fIdeleteProc\fR Tk will invoke \fIfreeProc\fR for
each of the image's instances.
\fIdeleteProc\fR must match the following prototype:
.CS
typedef void \fBTk_ImageDeleteProc\fR(
        ClientData \fImasterData\fR);
.CE
The \fImasterData\fR argument will be the same as the value
stored in \fI*masterDataPtr\fR by \fIcreateProc\fR when the
image was created.
\fIdeleteProc\fR should release any resources associated with
the image.
.SH TK_GETIMAGEMASTERDATA
.PP
The procedure \fBTk_GetImageMasterData\fR may be invoked to retrieve
information about an image.  For example, an image manager can use this
procedure to locate its image master data for an image.
If there exists an image named \fIname\fR
in the interpreter given by \fIinterp\fR, then \fI*typePtrPtr\fR is
filled in with type information for the image (the \fItypePtr\fR value
passed to \fBTk_CreateImageType\fR when the image type was registered)
and the return value is the ClientData value returned by the
\fIcreateProc\fR when the image was created (this is typically a
pointer to the image master data structure).  If no such image exists
then NULL is returned and NULL is stored at \fI*typePtrPtr\fR.
.SH "LEGACY INTERFACE SUPPORT"
.PP
In Tk 8.2 and earlier, the definition of \fBTk_ImageCreateProc\fR
was incompatibly different, with the following prototype:
.CS
typedef int \fBTk_ImageCreateProc\fR(
        Tcl_Interp *\fIinterp\fR,
        char *\fIname\fR,
        int \fIargc\fR,
        char **\fIargv\fR,
        Tk_ImageType *\fItypePtr\fR,
        Tk_ImageMaster \fImaster\fR,
        ClientData *\fImasterDataPtr\fR);
.CE
Legacy programs and libraries dating from those days may still
contain code that defines extended Tk image types using the old
interface.  The Tk header file will still support this legacy
interface if the code is compiled with the macro \fBUSE_OLD_IMAGE\fR
defined.
.PP
When the \fBUSE_OLD_IMAGE\fR legacy support is enabled, you may
see the routine \fBTk_InitImageArgs\fR in use.  This was a migration
tool used to create stub-enabled extensions that could be loaded
into interps containing all versions of Tk 8.1 and later.  Tk 8.5 no longer
provides this routine, but uses a macro to convert any attempted
calls of this routine into an empty comment.  Any stub-enabled
extension providing an extended image type via the legacy interface
that is compiled against Tk 8.5 headers and linked against the
Tk 8.5 stub library will produce a file that can be loaded only
into interps with Tk 8.5 or later; that is, the normal stub-compatibility
rules.  If a developer needs to generate from such code a file
that is loadable into interps with Tk 8.4 or earlier, they must
use Tk 8.4 headers and stub libraries to do so.
.PP
Any new code written today should not make use of the legacy
interfaces.  Expect their support to go away in Tk 9.
.SH "SEE ALSO"
Tk_ImageChanged, Tk_GetImage, Tk_FreeImage, Tk_RedrawImage, Tk_SizeOfImage
.SH KEYWORDS
image manager, image type, instance, master
@


1.15
log
@One more (hopefully the last) signature change
in Tk_CreatePhotoImageFormat
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.14 2008/06/30 22:57:01 dkf Exp $
d26 2
a27 2
.AS Tk_ImageType *typePtrPtr
.AP Tk_ImageType *typePtr in
d29 1
a29 1
Must be static: a
d31 1
d117 1
a117 1
        Tk_ImageType *\fItypePtr\fR,
@


1.14
log
@Minor doc updates (removing out of date changebars, improving typedef formatting,
 etc.)
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.13 2007/12/13 15:23:42 dgp Exp $
d63 1
a63 1
    char *\fIname\fR;
d113 1
a113 1
        char *\fIname\fR,
@


1.13
log
@merge stable branch onto HEAD
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.11.2.1 2007/12/10 18:39:27 dgp Exp $
a42 1

d69 1
a69 1
} Tk_ImageType;
a95 1

a103 1

d105 1
d111 8
a118 8
typedef int Tk_ImageCreateProc(
    Tcl_Interp *\fIinterp\fR,
    char *\fIname\fR,
    int \fIobjc\fR,
    Tcl_Obj *const \fIobjv\fR[],
    Tk_ImageType *\fItypePtr\fR,
    Tk_ImageMaster \fImaster\fR,
    ClientData *\fImasterDataPtr\fR);
a143 1

d150 3
a152 3
typedef ClientData Tk_ImageGetProc(
    Tk_Window \fItkwin\fR,
    ClientData \fImasterData\fR);
a163 1

d170 10
a179 10
typedef void Tk_ImageDisplayProc(
    ClientData \fIinstanceData\fR,
    Display *\fIdisplay\fR,
    Drawable \fIdrawable\fR,
    int \fIimageX\fR,
    int \fIimageY\fR,
    int \fIwidth\fR,
    int \fIheight\fR,
    int \fIdrawableX\fR,
    int \fIdrawableY\fR);
a195 1

d206 3
a208 3
typedef void Tk_ImageFreeProc(
    ClientData \fIinstanceData\fR,
    Display *\fIdisplay\fR);
a214 1

d224 2
a225 2
typedef void Tk_ImageDeleteProc(
    ClientData \fImasterData\fR);
a231 1

a244 1

d246 1
d250 8
a257 8
typedef int Tk_ImageCreateProc(
    Tcl_Interp *\fIinterp\fR,
    char *\fIname\fR,
    int \fIargc\fR,
    char **\fIargv\fR,
    Tk_ImageType *\fItypePtr\fR,
    Tk_ImageMaster \fImaster\fR,
    ClientData *\fImasterDataPtr\fR);
a280 1

a282 1

@


1.12
log
@Various markup fixes
(mostly: missing quotes on .SH arguments, extraneous .PPs)
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.11 2007/05/14 20:58:25 dgp Exp $
@


1.11
log
@        [Tk Bug 1712081]

        * unix/Makefile.in:     Updates to account for new and deleted files
        * win/Makefile.in:      tkStubImg.c and tkOldTest.c.
        * win/makefile.bc:
        * win/makefile.vc:

        * generic/tkOldTest.c (new):    New file used to create testing
        * generic/tkTest.c:             commands for testing various Tk
        * tests/constraints.tcl:        legacy interfaces where a separate
        * tests/image.test:             compilation unit is needed in order
        to #define suitable macros during compilation.  Only the effect of
        USE_OLD_IMAGE on Tk_CreateImageType() is currently tested, but more
        similar testing commands can be added to this same file.  New
        constraint defined to detect presence of the image type provided by
        the new testing code, and a few tests added to exercise it.  Having
        USE_OLD_IMAGE support tested by the default test suite should reduce
        chance of a recurrence of this bug.

        * doc/CrtImgType.3:     Revised docs to better indicate the legacy
        * doc/CrtPhImgFmt.3:    nature of the interfaces supported by
        USE_OLD_IMAGE.

        * generic/tkDecls.h:    make genstubs
        * generic/tkStubInit.c:

        * generic/tk.decls:             Reworked USE_OLD_IMAGE support to use
        * generic/tk.h:                 the same support mechanisms both with
        * generic/tkStubImg.c (deleted):and without a stub-enabled build.  In
        each case, route the legacy calls to Tk_CreateImageType and
        Tk_CreatePhotoImageFormat through the Tk_CreateOldImageType and
        Tk_CreateOldPhotoImageFormat routines.  Add those routines to the
        public stub table so they're available to a stub-enabled extension.
        Remove the definition of Tk_InitImageArgs() and use a macro to
        convert any calls to it in source code into a comment.

        * generic/tkImage.c:    Removed the MODULE_SCOPE declarations that
        * generic/tkImgPhoto.c: broke USE_OLD_IMAGE support.
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.10 2007/01/05 00:00:48 nijtmans Exp $
d253 1
a253 2
.SH LEGACY INTERFACE SUPPORT
.PP
@


1.11.2.1
log
@merge updates from HEAD
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.11 2007/05/14 20:58:25 dgp Exp $
d253 2
a254 1
.SH "LEGACY INTERFACE SUPPORT"
@


1.10
log
@various "const" additions, in line with TIP #27
fix bug #1627732
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.9 2005/04/06 21:11:53 dkf Exp $
d11 1
a11 1
.TH Tk_CreateImageType 3 8.3 Tk "Tk Library Procedures"
a106 10
.SS PORTABILITY
.PP
In Tk 8.2 and earlier, the createProc below had a different
signature. If you want to compile an image type using the
old interface which should still run on all Tcl/Tk versions,
compile it with the flag -DUSE_OLD_IMAGE. Further on, if
you are using Stubs, you need to call the function
Tk_InitImageArgs(interp, argc, &argv) first in your
createProc. See below for a description of this function.

d141 1
a141 1
message in \fIinterp->result\fR and return \fBTCL_ERROR\fR;  otherwise
d253 33
a285 1
.SH TK_INITIMAGEARGS
d287 2
a288 8
The function \fBTk_InitImageArgs\fR converts the arguments of the
\fBcreateProc\fR from objects to strings when necessary. When
not using stubs, not using the old interface, or running
under an older (pre-8.3) Tk version, this function has no
effect. This function makes porting older image handlers to
the new interface a lot easier: After running this function,
the arguments are guaranteed to be in string format, no
matter how Tk deliverd them.
@


1.9
log
@Purge old and inaccurate .VS/.VE macros.
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.8 2004/09/19 16:05:36 dkf Exp $
d33 1
a33 1
.AP "CONST char" *name in
d127 1
a127 1
    Tcl_Obj *CONST \fIobjv\fR[],
@


1.8
log
@Standardize style of section refs & public symbols. Remove displayed tabs
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.7 2003/12/10 09:42:17 dkf Exp $
a20 1
.VS
a41 1
.VE
a249 1
.VS
a261 1
.VE
a263 1
.VS
@


1.7
log
@Line transposition bug. [Bug 857159]
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.6 2002/08/05 04:30:38 dgp Exp $
d66 6
a71 6
	char *\fIname\fR;
	Tk_ImageCreateProc *\fIcreateProc\fR;
	Tk_ImageGetProc *\fIgetProc\fR;
	Tk_ImageDisplayProc *\fIdisplayProc\fR;
	Tk_ImageFreeProc *\fIfreeProc\fR;
	Tk_ImageDeleteProc *\fIdeleteProc\fR;
d100 1
a100 1
.SH NAME
d109 1
a109 1
.SH PORTABILITY
d119 1
a119 1
.SH CREATEPROC
d126 7
a132 7
	Tcl_Interp *\fIinterp\fR,
	char *\fIname\fR,
	int \fIobjc\fR,
	Tcl_Obj *CONST \fIobjv\fR[],
	Tk_ImageType *\fItypePtr\fR,
	Tk_ImageMaster \fImaster\fR,
	ClientData *\fImasterDataPtr\fR);
d159 1
a159 1
.SH GETPROC
d166 2
a167 2
	Tk_Window \fItkwin\fR,
	ClientData \fImasterData\fR);
d180 1
a180 1
.SH DISPLAYPROC
d187 9
a195 9
	ClientData \fIinstanceData\fR,
	Display *\fIdisplay\fR,
	Drawable \fIdrawable\fR,
	int \fIimageX\fR,
	int \fIimageY\fR,
	int \fIwidth\fR,
	int \fIheight\fR,
	int \fIdrawableX\fR,
	int \fIdrawableY\fR);
d213 1
a213 1
.SH FREEPROC
d224 2
a225 2
	ClientData \fIinstanceData\fR,
	Display *\fIdisplay\fR);
d233 1
a233 1
.SH DELETEPROC
d243 1
a243 1
	ClientData \fImasterData\fR);
@


1.6
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: CrtImgType.3,v 1.5 2000/07/25 21:14:34 jenglish Exp $
a19 1
ClientData
d22 1
@


1.6.2.1
log
@Line transposition bug. [Bug 857159]
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.6 2002/08/05 04:30:38 dgp Exp $
d20 1
a22 1
ClientData
@


1.5
log
@CanvPsY.3, ConfigWidg.3, CrtImgType.3, CrtItemType.3,
FontId.3, GetFont.3, canvas.n, font.n, options.n, text.n:
Documentation fix: Replaced references to XFontStruct *
and Tk_FontStruct with Tk_Font.
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.4 2000/02/08 11:31:30 hobbs Exp $
d34 1
a34 1
.AP char *name in
@


1.5.6.1
log
@merged with trunk at tag macosx-8-4-merge-2002-08-20-trunk
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id$
d34 1
a34 1
.AP "CONST char" *name in
@


1.4
log
@	* generic/tkDecls.h:
	* generic/tk.decls:
	* generic/tk.h: moved new public functions created in dash patch
	to the stubs interface [Bug: 4062]

	* generic/tk.h:
	* doc/CrtImgType.3:
	* doc/CrtPhImgFmt.3:
	* generic/tk.h:
	* generic/tkImgGIF.c:
	* generic/tkImgPhoto.c:
	* generic/tkStubImg.c (new file):
	* generic/tkTest.c:
	* unix/Makefile.in:
	* win/Makefile.in:
	* win/makefile.vc: improved support for moving from the old style
	image C API to the new obj'ified one with new Tk_InitImageArgs
	command and stub'ing of image code.  See docs for how to make the
	transition. [Bug: 4060]
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.3 1999/10/29 03:57:40 hobbs Exp $
d39 1
a39 1
.AP int argc
d41 1
a41 1
.AP char ***argvPtr
@


1.4.2.1
log
@doc cleanup and clarifications from 8.4aCVS backport
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.5 2000/07/25 21:14:34 jenglish Exp $
d39 1
a39 1
.AP int argc in
d41 1
a41 1
.AP char ***argvPtr in/out
@


1.3
log
@	* doc/CrtImgType.3:
	* doc/CrtPhImgFmt.3:
	* doc/FindPhoto.3:
	* doc/photo.n: new docs for Img patch mods
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id: CrtImgType.3,v 1.2 1998/09/14 18:22:46 stanton Exp $
d11 1
a11 1
.TH Tk_CreateImageType 3 8.0 Tk "Tk Library Procedures"
d14 1
a14 1
Tk_CreateImageType, Tk_GetImageMasterData \- define new kind of image
d24 2
d39 4
d109 10
d266 12
@


1.2
log
@Replaced SCCS strings, fixed binary files
@
text
@d8 1
a8 1
'\" RCS: @@(#) $Id$
d112 2
a113 2
	int \fIargc\fR,
	char **\fIargv\fR,
d122 1
a122 1
The \fIargc\fR and \fIargv\fR arguments describe all the configuration
d128 1
a128 1
Typically \fIcreateProc\fR will parse \fIargc\fR and \fIargv\fR
@


1.1
log
@Initial revision
@
text
@d8 1
a8 1
'\" SCCS: @@(#) CrtImgType.3 1.9 97/08/08 15:43:15
@


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


