[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