-disablecallback"
option do?
-value option and a
-command option. Any modification of the
-value will cause the -command callback
to be executed. Sometimes this is undesirable. For example,
calling "config -value" inside the callback procedure
will cause the callback to be re-entered and thus an infinite
recursion.
The -disablecallback can be used to advoid this
problem. When this option is set, the -command
callback will not be executed even if the -value of a widget is
changed. Therefore, if you need to modify the -value of a widget
inside its callback, do this:
proc my_callback {w} {
$w config -disablecallback true
$w config value blah
$w config -disablecallback false
}
proc my_callback {w} {
tixSetSilent $w blah
}
option add *TixControl*entry.width 10OR
tixControl .c -options {
entry.width 10
}
(TixForm) Error:Trying to use more than one geometry
manager for the same master window.
Giving up after 50 iterations.
Most likely, the problem is when using tixLabelFrame widgets, you
packed to the wrong frame: This is WRONG:
tixLabelFrame .d
button .d.b
pack .d.b
This is the correct way:
tixLabelFrame .d
set f [.d subwidget frame]
button $f.b
pack $f.b
pack .d
Remember you don't pack directly into a TixLabelFrame
widget. Instead, you should pack into its frame
subwidget.
tclIndex file for Tix?
tclIndex files cannot be generated using the
standard auto_mkindex procedure. You must use the tixindex program
in the tools/ subdirectory in the Tix
distribution. The syntax is
tixindex *.tcl
-command and -browsecmd options?
tixBreak command. For example:
tixFileSelectDialog .c -command "puts foo; tixBreak"
tixWidgetDoWhenIdle do?
tixWidgetDoWhenIdle tixComboBox::Update $w blah blah ..will execute tixComboBox::Update only if $w exists. $w may be destroyed after tixWidgetDoWhenIdle is called but before an idle event happens.
We can't guarantee to implement the requested features immediately. Usually it depends on how important the features. If the feature is requested by more people, it will usually get done faster. However, some frequently requested features probably won't be imlemented. Usually these features are cosmetic changes and:
Some examples are:
-browsecmd gets called
twice. However, I just want it to be called once.
-browsecmd procedure is triggered by three types
of events: <1>,
<ButtonRelease-1>, and
<B1-Motion>. When the user clicks on an entry,
a <1> and a
<ButtonRelease-1> event will happen in rapid
session, which causes your -browsecmd procedure to be
called twice.
A crude fix for this problem is to ignore all the
<ButtonRelease-1> events. You can find out the
event that triggers the -browsecmd procedure by the
tixEvent command. Here is an example:
tixDirList .c -browsecmd Browse
proc Browse {args} {
if {[tixEvent type] == "<ButtonRelease-1>"} {
return
}
# ....
}
<1> on entry one.
<B1-Motion> on entry two.
<ButtonRelease-1> on entry three.
Therefore, if you use the above method, the browse event on entry three will be lost!
To devise a better solution, it's better to understand the basic design conventions of a Tix-based GUI. Suppose we have a list of entries displayed in a listbox (or DirList, or HList). When the user clicks on an entry, the GUI usually responds by displaying a "detailed view" of the entry. For example, if we put a list of file names in a listbox, when the user clicks on a file name, we display the contents of the file in a text window. If the user then clicks on another file name, the text window will load in the contents of the new file.
Now what happens if the user clicks on the same entry twice? Do we reload the contents of the file into the text window? This is usually unnecessary, inefficient and probably not what the user wants to do. The Tix convention is, when the user clicks on the same entry again, the detail view is not updated. If the user wants to force an update (e.g, the user knows the file's contents has been changed and wants to see the new version), he or she can double-click on the entry and the application will respond by redisplaying the detail view (reloading the file).
To implement this policy, the Browse procedure should be modified as the following:
proc Browse {args} {
global currentView
set ent [tixEvent value]
if {$ent == $currentView} {
# We have already displayed the detailed view of $ent.
#
return
} else {
set currentView $ent
DisplayDetail $ent
}
}
tixExFileSelectDialog .f -command foo
foo {filename} {
destroy .f
do some other stuff ...
}
it will cause a Tcl error because the dialog assumes that it still
exists after calling your command. This usually result in errors like
this:
can't read "data(-value)": no such element in array while executing "set data(-selection) $data(-value)..." (procedure "tixComboBox::SetValue" line 30)This "feature" is built into many Tix widgets and can't be fixed easily. To work around the problem, never destroy widgets inside -command calls. Usually you should unmap toplevel windows instead. If you must destroy widgets, do it with an "after" command. For example, the foo procedure should be rewritten as:
foo {filename} {
wm withdraw .f
do some other stuff ...
after idle {if [winfo exists .f] {destroy .f}}
}
Execute the "after" command at the very end of the
-command. Otherwise the idle handler may be activated by some
"update" calls.
# ./configure --prefix=/usr/vendor/tcl
loading cache ./config.cache
checking for a BSD compatible install... /usr/bin/installbsd -c
checking for ranlib... ranlib
checking how to run the C preprocessor... cc -E
checking for unistd.h... ./configure[603]: "${ac_cv_header_$ac_safe+set}": bad
substitution
make distclean ./configure make all