[GRASS5] [bug #4024] (grass) d.m, v.in.ascii: columns hint leads to errors

[Michael Barton]

Right. It just that the GUI that is being discussed is the one that is
automatically generated from text in main.c, not from anything in the d.m.

My version of r.in.ascii (9 January 2006) does not match what Maciek is
describing. However, there are some 'hints' put into the fields that should
probably be in the field descriptions.

I just looked at main.c for r.in.ascii on the web cvs. Here is the relevant
code:

    parm.mult = G_define_option();
    parm.mult->key = "mult";
    parm.mult->type = TYPE_DOUBLE;
    parm.mult->answer = "1.0 or read from header";
    parm.mult->required = NO;
    parm.mult->description = _("Multiplier for ascii data") ;

    parm.nv = G_define_option();
    parm.nv->key = "nv";
    parm.nv->type = TYPE_STRING;
    parm.nv->required = NO;
    parm.nv->multiple = NO;
    parm.nv->answer = "* or read from header";
    parm.nv->description = _("String representing NULL value data cell");


The lines " parm.nv->answer = ..." put a string into the field as a default.
It looks like a 'hint' was put here to help the user decide what to put in
the field. However, this is supposed to be a default value rather than a
hint. 

What I take this to mean is that for nv, you can put in a string ("*" being
a default string to use) to indicate null values or you can leave this blank
and GRASS will attempt to find a null value string specified in the file
header. 

Given that GRASS could also look for a field value multiplier in the file
header, a better way to do this might be to make a flag (-h perhaps) that
tell GRASS to look in the file header for null value and multiplier
specifications. Otherwise, look in the r.in.ascii arguments nv and mult.
Then "*" and "1.0" could be left in as default values that actually work,
without the added "or read from header". There is probably a need for more
room for field entry description as this is done in a number of other places
too. For example, something like 1-100 is often put into fields to mean that
you need to enter a value between 1 and 100, and to limit acceptable values
to the 1-100 range.

Michael

On 1/21/06 9:56 PM, "Hamish" <hamish_nospam at yahoo.com> wrote:

>> The manual page is built out of the module descriptions in the
>> C-code. If I've got this right, then the updates need to go to the
>> code (I think it's main.h or something like that). This would improve
>> both the module GUI and documentation.
> 
> main.c, yes. help page header is created with "g.module
> --html-description"
> from the GRASS prompt. Code to make the Tcl/Tk window is created with
> "g.module --tcltk". Try it.
> 
> As for v.in.ascii coulmns=, I don't think the problem is in the
> description, that seems clear enough to me. I'm all for making things
> easier on the users but figuring out you have to remove the quotes from
> around an example is pretty basic. (yes, I've made that same mistake)
> If there is a problem in the GUI it is from the GUI assuming too much
> from the description, or descriptive text existing in the options
> section.
> 
> What I am trying to say is don't change the C code to mask mistakes in
> the GUI.. fix the GUI.
> 
> Of course if a description _is_ really misleading or confusing there's
> grounds to change it.
> 
> 
> Hamish

___________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287

WWW - http://www.public.asu.edu/~cmbarton
Phone: 480-965-6262
Fax: 480-965-7671