[GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows

[Michael Barton]

On 9/3/07 7:11 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>> I just put in a large number of error message boxes instead of routing
>> errors to the terminal.
>> 
>> In general, it has generally seemed like a better idea to use a built in
>> TclTk tool like tk_messageBox if one was available, than to use a custom
>> function that we have to maintain to do the same thing. In the x11 version I
>> use on my Mac, I kind of like the looks of tk_messageBox better than
>> DialogGen, but that's just a matter of personal opinion.
>> 
>> But I don't have a sense of what the difference between the two is on
>> Windows and would always like to have a better looking interface. It might
>> be nice to have error reporting have a consistent look across the entire
>> program--either DialogGen or tk_messageBox. And if there is a general
>> preference to the custom function (DialogGen) I don't feel that strongly
>> about it either way--as long as someone else wants to change over the 130+
>> of tk_messageBox dialogs I just installed ;-).
> 
> If you find yourself typing 130+ instances of near-identical code,
> that should be a clue that you should add some more infrastrcture.
> 
> For a start, if you add:
> 
> proc errorBox {msg} {
>     tk_messageBox -type ok -icon error -title [G_msg "Error"] -message $msg
> }
> 
> you would be able to replace e.g.:
> 
> tk_messageBox -type ok -icon error -title [G_msg "Error"] \
> -message [G_msg "Error creating tempfile: $error"]
> 
> (of which I see at least 102 occurrences) with just:
> 
> errorBox [G_msg "Error creating tempfile: $error"]

Agreed that this reduces the number of characters in the code. But it isn't
much different timewise for cutting and pasting. It would make it easier to
globally format all error messages in the future.

> 
> [
> BTW, this usage of G_msg is probably incorrect, as the entire message,
> including $error, will be used as the key. It should probably be:
> 
> errorBox "[G_msg {Error creating tempfile}]: $error"
> 
> or even:
> 
> errorBox "[G_msg {Error creating tempfile}]: [G_msg $error]"
> 
> so that "Error creating tempfile" and the error message will be
> translated independently. This means that you only need A+B
> translations instead of A*B. The second G_msg is only necessary if
> Tcl/Tk error messages aren't already localised by Tcl/Tk.
> 
> Note that the situation is different with C, where "%s" is included
> literally in the message key. In Tcl, $error will be substituted
> before the message is translated.
> ]

This is important to know for internationalization. Probably worth going
back and redoing. An error function probably wouldn't have made this any
easier unfortunately.

> 
> Beyond that, the common error-trapping idioms for exec can be
> incorporated into functions, e.g. (untested):
> 
> proc execNoError {cmd args} {
> if {[catch {set result [eval exec [list $cmd] $args]} result]} {
> tk_messageBox -type ok -icon error -title [G_msg "Error"] -message [G_msg
> $result]
> # force the caller to return
> uplevel 1 return
> }
> return $result
> }
> 
> This would allow simple cases to avoid explicit error handling
> altogether.

In retrospect, it would have been better to have a single command processing
function that used arguments or flags to merge the multiple ones now in the
TclTk GUI (run, run_ui, execute, ...) and handle error trapping at the same
time--as per Hamish' comments in a related thread and as we're doing with
cmd.Command in wxgrass. It's quite a bit of work to go back and fix this in
TclTk. If we were keeping the TclTk GUI into the future, it would definitely
be worth the effort. I'm not sure it is now, given that we're switching to
wxPython.

Michael


__________________________________________
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