[GRASS-dev] Re: grass-dev Digest, Vol 21, Issue 1
Glynn Clements
glynn at gclements.plus.com
Fri Jan 4 07:37:19 EST 2008
Michael Barton wrote:
> > Gm::errmsg belongs in a "library", i.e. a Tcl source file which can be
> > "source"d from other Tcl source files.
> >
> > Also: gm.tcl calls Gm::errmsg from top-level code at the beginning of
> > the file (the code which copies various g.gisenv settings into $env),
> > although the procedure isn't actually defined until much later in the
> > file. If any of those "catch" statements actually catch an error, the
> > handler will throw an error due to Gm::errmsg being undefined.
>
> Making a library and moving Gm::errmsg to it is pretty easy to fix
> (just a LOT of find/replace throughout the GUI code). Anything else
> that you know of should come out of gm.tcl and into such a library?
One option is to make gm.tcl the library and put the gis.m "main" in a
different file. The function would still be called Gm::errmsg.
Everything up to the "proc Gm::create" line should probably be in a
library, while the stuff following is specific to the gis.m
application.
> However, making the 'get system info' function work is more trouble.
> As I said in the rest of the post, it's very old code. Is it worth
> bothering with to have the GUI launch a window with a bit of minimal
> system info?
It might be useful for dealing with gis.m bug reports.
AFAICT, the only reason it stopped working was the botched conversion
to using Gm:errmsg.
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list