On Mar 30, 2008, at 2:17 AM, Glynn Clements wrote:
Michael Barton wrote:
Date: Fri, 28 Mar 2008 23:24:36 +0600
From: Ivan Shmakov <[EMAIL PROTECTED]>
Subject: [GRASS-dev] gui/tcltk/gis.m/*.tcl: wrong `variable' syntax
To: [email protected]
Cc: Ivan Shmakov <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
The lines marked ``>'' below seem nonsensical to me. For what
reason, e. g., would one need to assign to an `array' variable
thrice, let alone introducing the `#' variable?
barscale.tcl 12 namespace eval GmBarscale {
barscale.tcl 13 > variable array opt # barscale current options
barscale.tcl 14 variable count 1
barscale.tcl 15 > variable array lfile # scale
barscale.tcl 16 > variable array lfilemask # scale
barscale.tcl 17 variable optlist
barscale.tcl 18 variable first
barscale.tcl 19 > variable array dup # layer
barscale.tcl 20 > variable placement #LabelEntry widget for
scale bar placment coordinates
barscale.tcl 21 };
Ivan,
Everything following the # is a comment to document the variable
No it isn't. It may have been *intended* as a comment, but the #
character is only treated as starting a comment when it occurs at the
beginning of a command, e.g. at the beginning of a line, or following
a semicolon.
I got this syntax from prior TclTk code. This is what happens when
you learn a language in that way. So we just need to move all these
to their own line
From the Tcl(n) manpage:
[9] Comments.
If a hash character (``#'') appears at a point
where Tcl is
expecting the first character of the first word of
a command,
then the hash character and the characters that
follow it, up
through the next newline, are treated as a comment
and ignored.
The comment character only has significance when it
appears at
the beginning of a command.
It's quite common for people to get bitten by this. Most of the time,
you just get a syntax error, but in this case the code is legal (it
just doesn't do what you expect).
There is one place that is a serious problem where we could really
use a much more experienced TclTk programmer like you to sort out:
the progress bar. It seems like it ought to be straightforward, but
there is something wrong with the progress bar code so that if a
module executes too quickly, it crashes the entire TclTk interface.
AFAICT, the issue is due to an event handler being re-entered through
the "update" command.
I note that ProgressBar::_modify calls update. One option is to remove
that call. Any other options (i.e. allowing event handlers to be
re-entered) are quite complex.
I'll try this as soon as I can get back to doing this. Thanks.
Michael
--
Glynn Clements <[EMAIL PROTECTED]>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
