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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
