[GRASS-dev] Re: grass-dev Digest, Vol 23, Issue 112

[Glynn Clements]

Michael Barton wrote:

> > Date: Fri, 28 Mar 2008 23:24:36 +0600
> > From: Ivan Shmakov <ivan at theory.asu.ru>
> > Subject: [GRASS-dev] gui/tcltk/gis.m/*.tcl: wrong `variable' syntax
> > To: grass-dev at lists.osgeo.org
> > Cc: Ivan Shmakov <oneingray at gmail.com>
> > Message-ID: <m263v67odn.fsf at cherry.siamics.int>
> > 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.

>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.

-- 
Glynn Clements <glynn at gclements.plus.com>