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 ;-).
On a different error trap note...anyone have a feel for whether it's
worthwhile to use this check for all error traps?
if {[lindex $::errorCode 0] eq "CHILDSTATUS"} {
if it returns better information, it might be worth the effort.
Cheers
Michael
On 9/2/07 4:11 AM, "Paul Kelly" <[EMAIL PROTECTED]> wrote:
> Hello Maris
>
> On Sun, 2 Sep 2007, Maris Nartiss wrote:
>
>> Sorry for jumping-in.
>> I may be not following hard enough, but I just tested error catching
>> in lib/init/file_option.tcl proc fileOpt::create_loc and it works in
>> both cases:
>> 1) Try to create new location from GDAL unsupported file -> outputs
>> g.proj error;
>> 2) Move all GDAL libs to some other place and then try to create new
>> location -> outputs "shared library not found" error.
>> IMHO both of them are most common errors and having reported to user
>> in some user-friendly way is good thing. Any other common problem that
>> should be tested?
>
> Yes I think it works quite well there. I copied some of what you did in
> file_option.tcl for my recent improvements to epsg_option.tcl. The way I
> see it is that because the catch function takes an optional argument - a
> variable to catch whatever is written to stderr - there is no need to
> redirect stderr to a file. In effect we use the catch command to "catch"
> the stderr output.
>
> DialogGen works well for popping up clear error messages with the same
> look and file as the rest of the GUI (in fact I changed it so the border
> on the OK button looks the same as the other buttons in gis_set.tcl and
> associated dialogs). tk_messageBox (on Windows anyway) resulted in a
> dialog box with a totally different look and feel and to me at least it
> seemed a bit inconsistent in regard to which windows it popped up in front
> of. I wouldn't recommend using it - I changed a couple of occurences of it
> in epsg_option.tcl to use DialogGen instead.
>
> Paul
>
>
__________________________________________
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
