'\" '\" Copyright (c) 1993 The Regents of the University of California. '\" Copyright (c) 1994-1996 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: LinkVar.3,v 1.6.2.1 2003/07/18 16:56:24 dgp Exp $ '\" .so man.macros .TH Tcl_LinkVar 3 7.5 Tcl "Tcl Library Procedures" .BS .SH NAME Tcl_LinkVar, Tcl_UnlinkVar, Tcl_UpdateLinkedVar \- link Tcl variable to C variable .SH SYNOPSIS .nf \fB#include \fR .sp int \fBTcl_LinkVar\fR(\fIinterp, varName, addr, type\fR) .sp \fBTcl_UnlinkVar\fR(\fIinterp, varName\fR) .sp \fBTcl_UpdateLinkedVar\fR(\fIinterp, varName\fR) .SH ARGUMENTS .AS Tcl_Interp writable .AP Tcl_Interp *interp in Interpreter that contains \fIvarName\fR. Also used by \fBTcl_LinkVar\fR to return error messages. .AP "CONST char" *varName in Name of global variable. .AP char *addr in Address of C variable that is to be linked to \fIvarName\fR. .AP int type in Type of C variable. Must be one of TCL_LINK_INT, TCL_LINK_DOUBLE, .VS 8.4 TCL_LINK_WIDE_INT, .VE 8.4 TCL_LINK_BOOLEAN, or TCL_LINK_STRING, optionally OR'ed with TCL_LINK_READ_ONLY to make Tcl variable read-only. .BE .SH DESCRIPTION .PP \fBTcl_LinkVar\fR uses variable traces to keep the Tcl variable named by \fIvarName\fR in sync with the C variable at the address given by \fIaddr\fR. Whenever the Tcl variable is read the value of the C variable will be returned, and whenever the Tcl variable is written the C variable will be updated to have the same value. \fBTcl_LinkVar\fR normally returns TCL_OK; if an error occurs while setting up the link (e.g. because \fIvarName\fR is the name of array) then TCL_ERROR is returned and the interpreter's result contains an error message. .PP The \fItype\fR argument specifies the type of the C variable, and must have one of the following values, optionally OR'ed with TCL_LINK_READ_ONLY: .TP \fBTCL_LINK_INT\fR The C variable is of type \fBint\fR. Any value written into the Tcl variable must have a proper integer form acceptable to \fBTcl_GetIntFromObj\fR; attempts to write non-integer values into \fIvarName\fR will be rejected with Tcl errors. .TP \fBTCL_LINK_DOUBLE\fR The C variable is of type \fBdouble\fR. Any value written into the Tcl variable must have a proper real form acceptable to \fBTcl_GetDoubleFromObj\fR; attempts to write non-real values into \fIvarName\fR will be rejected with Tcl errors. .TP \fBTCL_LINK_WIDE_INT\fR .VS 8.4 The C variable is of type \fBTcl_WideInt\fR (which is an integer type at least 64-bits wide on all platforms that can support it.) Any value written into the Tcl variable must have a proper integer form acceptable to \fBTcl_GetWideIntFromObj\fR; attempts to write non-integer values into \fIvarName\fR will be rejected with Tcl errors. .VE 8.4 .TP \fBTCL_LINK_BOOLEAN\fR The C variable is of type \fBint\fR. If its value is zero then it will read from Tcl as ``0''; otherwise it will read from Tcl as ``1''. Whenever \fIvarName\fR is modified, the C variable will be set to a 0 or 1 value. Any value written into the Tcl variable must have a proper boolean form acceptable to \fBTcl_GetBooleanFromObj\fR; attempts to write non-boolean values into \fIvarName\fR will be rejected with Tcl errors. .TP \fBTCL_LINK_STRING\fR The C variable is of type \fBchar *\fR. .VS If its value is not NULL then it must be a pointer to a string allocated with \fBTcl_Alloc\fR or \fBckalloc\fR. .VE Whenever the Tcl variable is modified the current C string will be freed and new memory will be allocated to hold a copy of the variable's new value. If the C variable contains a NULL pointer then the Tcl variable will read as ``NULL''. .PP If the TCL_LINK_READ_ONLY flag is present in \fItype\fR then the variable will be read-only from Tcl, so that its value can only be changed by modifying the C variable. Attempts to write the variable from Tcl will be rejected with errors. .PP \fBTcl_UnlinkVar\fR removes the link previously set up for the variable given by \fIvarName\fR. If there does not exist a link for \fIvarName\fR then the procedure has no effect. .PP \fBTcl_UpdateLinkedVar\fR may be invoked after the C variable has changed to force the Tcl variable to be updated immediately. In many cases this procedure is not needed, since any attempt to read the Tcl variable will return the latest value of the C variable. However, if a trace has been set on the Tcl variable (such as a Tk widget that wishes to display the value of the variable), the trace will not trigger when the C variable has changed. \fBTcl_UpdateLinkedVar\fR ensures that any traces on the Tcl variable are invoked. .SH KEYWORDS boolean, integer, link, read-only, real, string, traces, variable 7 Tk is a free and open-source, cross-platform widget toolkit that provides a library of basic elements of GUI widgets for building a graphical user interface (GUI) in many programming languages.
summaryrefslogtreecommitdiffstats
path: root/doc/CrtWindow.3
blob: 7799ed013ce01c38887a2a2ff50daae79475a321 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
'\"
'\" Copyright (c) 1990 The Regents of the University of California.
'\" Copyright (c) 1994-1996 Sun Microsystems, Inc.
'\"
'\" See the file "license.terms" for information on usage and redistribution
'\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
'\" 
'\" @(#) CrtWindow.c 1.21 96/11/01 09:42:20
'\" 
.so man.macros
.TH Tk_CreateWindow 3 4.2 Tk "Tk Library Procedures"
.BS
.SH NAME
Tk_CreateWindow, Tk_CreateWindowFromPath, Tk_DestroyWindow, Tk_MakeWindowExist \- create or delete window
.SH SYNOPSIS
.nf
\fB#include <tk.h>\fR
.sp
Tk_Window
\fBTk_CreateWindow\fR(\fIinterp, parent, name, topLevScreen\fR)
.sp
Tk_Window
\fBTk_CreateWindowFromPath\fR(\fIinterp, tkwin, pathName, topLevScreen\fR)
.sp
\fBTk_DestroyWindow\fR(\fItkwin\fR)
.sp
\fBTk_MakeWindowExist\fR(\fItkwin\fR)
.SH ARGUMENTS
.AS Tcl_Interp *topLevScreen
.AP Tcl_Interp *interp out
Tcl interpreter to use for error reporting.  If no error occurs,
then \fI*interp\fR isn't modified.
.AP Tk_Window parent in
Token for the window that is to serve as the logical parent of
the new window.
.AP char *name in
Name to use for this window.  Must be unique among all children of
the same \fIparent\fR.
.AP char *topLevScreen in
Has same format as \fIscreenName\fR.  If NULL, then new window is
created as an internal window.  If non-NULL, new window is created as
a top-level window on screen \fItopLevScreen\fR.  If \fItopLevScreen\fR
is an empty string (``'') then new
window is created as top-level window of \fIparent\fR's screen.
.AP Tk_Window tkwin in
Token for window.
.AP char *pathName in
Name of new window, specified as path name within application
(e.g. \fB.a.b.c\fR).
.BE

.SH DESCRIPTION
.PP
The procedures \fBTk_CreateWindow\fR
.VS
and \fBTk_CreateWindowFromPath\fR
are used to create new windows for
use in Tk-based applications.  Each of the procedures returns a token
that can be used to manipulate the window in other calls to the Tk
library.  If the window couldn't be created successfully, then NULL
is returned and \fIinterp->result\fR is modified to hold an error
message.
.PP
Tk supports two different kinds of windows:  internal
windows and top-level windows.
.VE
An internal window is an interior window of a Tk application, such as a
scrollbar or menu bar or button.  A top-level window is one that is
created as a child of a screen's root window, rather than as an
interior window, but which is logically part of some existing main
window.  Examples of top-level windows are pop-up menus and dialog boxes.
.PP
New windows may be created by calling
\fBTk_CreateWindow\fR.  If the \fItopLevScreen\fR argument is
NULL, then the new window will be an internal window.  If
\fItopLevScreen\fR is non-NULL, then the new window will be a
top-level window: \fItopLevScreen\fR indicates the name of
a screen and the new window will be created as a child of the
root window of \fItopLevScreen\fR.  In either case Tk will
consider the new window to be the logical child of \fIparent\fR:
the new window's path name will reflect this fact, options may
be specified for the new window under this assumption, and so on.
The only difference is that new X window for a top-level window
will not be a child of \fIparent\fR's X window.  For example, a pull-down
menu's \fIparent\fR would be the button-like window used to invoke it,
which would in turn be a child of the menu bar window.  A dialog box might
have the application's main window as its parent.
.PP
\fBTk_CreateWindowFromPath\fR offers an alternate way of specifying
new windows.  In \fBTk_CreateWindowFromPath\fR the new
window is specified with a token for any window in the target
application (\fItkwin\fR), plus a path name for the new window.
It produces the same effect as \fBTk_CreateWindow\fR and allows
both top-level and internal windows to be created, depending on
the value of \fItopLevScreen\fR.  In calls to \fBTk_CreateWindowFromPath\fR,
as in calls to \fBTk_CreateWindow\fR, the parent of the new window
must exist at the time of the call, but the new window must not
already exist.
.PP
The window creation procedures don't
actually issue the command to X to create a window.
Instead, they create a local data structure associated with
the window and defer the creation of the X window.
The window will actually be created by the first call to
\fBTk_MapWindow\fR.  Deferred window creation allows various
aspects of the window (such as its size, background color,
etc.) to be modified after its creation without incurring
any overhead in the X server.  When the window is finally
mapped all of the window attributes can be set while creating
the window.
.PP
The value returned by a window-creation procedure is not the
X token for the window (it can't be, since X hasn't been
asked to create the window yet).  Instead, it is a token
for Tk's local data structure for the window.  Most
of the Tk library procedures take Tk_Window tokens, rather
than X identifiers.  The actual
X window identifier can be retrieved from the local
data structure using the \fBTk_WindowId\fR macro;  see
the manual entry for \fBTk_WindowId\fR for details.
.PP
\fBTk_DestroyWindow\fR deletes a window and all the data
structures associated with it, including any event handlers
created with \fBTk_CreateEventHandler\fR.  In addition,
\fBTk_DestroyWindow\fR will delete any children of \fItkwin\fR
recursively (where children are defined in the Tk sense, consisting
of all windows that were created with the given window as \fIparent\fR).
If \fItkwin\fR was created by \fBTk_CreateInternalWindow\fR then event
handlers interested in destroy events
are invoked immediately.  If \fItkwin\fR is a top-level or main window,
then the event handlers will be invoked later, after X has seen
the request and returned an event for it.
.PP
If a window has been created
but hasn't been mapped, so no X window exists, it is
possible to force the creation of the X window by
calling \fBTk_MakeWindowExist\fR.  This procedure issues
the X commands to instantiate the window given by \fItkwin\fR.

.SH KEYWORDS
create, deferred creation, destroy, display, internal window,
screen, top-level window, window