[GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows
Glynn Clements
glynn at gclements.plus.com
Mon Sep 3 10:11:06 EDT 2007
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"]
[
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.
]
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.
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list