On Thu, 2007-08-23 at 23:15 -0700, Michael Barton wrote:
I've gone through and wrapped in catch statements all GRASS commands worth
wrapping (and probably some not worth it).
I also did a bit of cleanup to the help routines that I ran across.
I also added Carlos' get info buttons to the raster and vector layer panels.
These are quite handy.
There is a bug in v.what such that it kicks out the wrong stuff with its GUI
interface description. Only shows up from the GUI, but it would be nice if
it could be fixed.
Anything else GUI-wise broken and fixable that anyone has noticed?
There still seems to be a nviz GUI redesign related problem
(it may be due to my set up, but Paul said
that he has a problem with Save state on his freshly checked GRASS CVS
too.)
I have compared nviz in 6.2.1 that had older interface and Save State
works there (at least to some extent) with 6.3 and the state
files are indeed different - in 6.3 the light data are missing and the
order of saved settings is different (the later may not matter).
But the real problem is that nviz in 6.3
cannot read the saved settings and I get the following error:
Diagnostic: wrong # args: should be "set varName ?newValue?" -- Load
procedure for panel main may not be defined
Diagnostic: invalid command name "Nviz_720 752_load" -- Load procedure
for panel 720 752 may not be defined
Diagnostic: invalid command name "Nviz_22.0_load" -- Load procedure for
panel 22.0 may not be defined
Diagnostic: invalid command name "Nviz_4.462_load" -- Load procedure
for panel 4.462 may not be defined
Diagnostic: invalid command name "Nviz_379.50_load" -- Load procedure
for panel 379.50 may not be defined
Diagnostic: invalid command name "Nviz_0.504 0.984_load" -- Load
procedure for panel 0.504 0.984 may not be defined
Diagnostic: invalid command name "Nviz_1_load" -- Load procedure for
panel 1 may not be defined
Diagnostic: invalid command name "Nviz_234.500000 234.500000
120.363991_load" -- Load procedure for panel 234.500000 234.500000
120.363991 may not be defined
There is also a problem with scripts - I don't think it is directly in
the file sequencing tool as I assume that it has not been touched, but
some of the recent changes must have affected handling of map names:
section of nviz script created by file sequencing tool
old that worked:
if {$iloop4 < 8} then {
if {[lsearch {} $iloop4] == -1} then {
if {[lsearch {} $iloop4] > -1} then {
SendScriptLine "lappend NVIZ_BLANK_MAPS [ExtractMapID $mhandle6]"
} else {
SendScriptLine "$mhandle6 set_att color [lindex {hfl.sig100@indyfi
hfl.sig10@indyfi hfl.sig1@indyfi hfl.sig05@indyfi hfl.sig03@indyfi
hfl.sig01@indyfi hfl.sig005@indyfi hfl.sig001@indyfi} $iloop4]"
}
new that does not work for obvious reasons (full path instead of
rastername@mapset) :
if {$iloop3 < 1} then {
if {[lsearch {} $iloop3] == -1} then {
if {[lsearch {} $iloop3] > -1} then {
SendScriptLine "lappend NVIZ_BLANK_MAPS [ExtractMapID $mhandle4]"
} else {
SendScriptLine "$mhandle4 set_att topo [lindex
{/local/home/helena/grassdata07/nc_spm_05/user1/cell/elev_lidtopandef_1m@user1} $iloop3]"
The reason for the above problem seems to be that the save fields
function saves full path instead of name@mapset
/local/home/helena/limg/grassbook/dynsurf.state.nviz
2
Surface
Topography
surf*1185562518
1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/elev_lidtopandef_1m@user1
Surface
Color
surf*1185562518
5
/local/home/helena/grassdata07/nc_spm_05/user1/cell/distr_2m.0418@user1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/distr_2m.0438@user1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/distr_2m.0458@user1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/distr_2m.0478@user1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/distr_2m.0498@user1
the old field file has just
distr_2m.0418@user1
distr_2m.0438@user1
I am hoping that the fix is not too complex,
Helena
Michael
On 8/22/07 4:22 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:
>>> A couple of side-notes though:
>>> 1) In general the GUI is terrible at catching and reporting errors from
>>> modules it calls in the background and this leads to cryptic error
>>> messages or nothing happening all over the place. IMHO it is a really
>>> pervasive problem that definitely needs fixed in the next GUI. Hopefully
>>> it already is there (ISTR discussions about every call to a GRASS module
>>> going through some other function where the error trapping could
>>> presumably be added, to avoid code repetition).
>>
>> Actually, error trapping is pretty good in the GUI now, except for NVIZ (but
>> which doesn't run much in the way of GRASS commands anyway). There are traps
>
> Well maybe I was being a bit overly dramatic, but running
> grep "exec " *.tcl | grep -v catch | wc -l
> in the gis.m directory still reveals 72 lines where exec is used without a
> corresponding catch. Not very scientific and perhaps not important in most
> cases - but if a single command (be it a GRASS module or system command)
> is not available or not working for some reason it could really make the
> difference between somebody tearing their hair out for a day or finding
> the source of a problem quickly.
>
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev