[GRASS5] [bug #1634] (grass) d.mapgraph: survive redraw?

this bug's URL: http://intevation.de/rt/webrt?serial_num=1634
-------------------------------------------------------------------------

Subject: d.mapgraph: survive redraw?

Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: 5.0.0

It would be nice if someone could figure out how to get d.mapgraph to survive a redraw or zoom.

Currently the call to D_add_to_list(G_recreate_command()) is commented out, as the program can take input from stdin, which doesn't get saved to the print list.

maybe
if(opt1->answer != NULL) {
    D_add_to_list(G_recreate_command()) ;
}

instead, i.e. add to the print list only if input comes from an actual disk file.. better than nothing anyway.

any ideas? prepend the stdin input and some pipes to the d.mapgraph command line string?

Hamish

-------------------------------------------- Managed by Request Tracker

Request Tracker wrote:

It would be nice if someone could figure out how to get d.mapgraph to
survive a redraw or zoom.

Currently the call to D_add_to_list(G_recreate_command()) is commented
out, as the program can take input from stdin, which doesn't get saved
to the print list.

instead, i.e. add to the print list only if input comes from an actual
disk file.. better than nothing anyway.

any ideas? prepend the stdin input and some pipes to the d.mapgraph
command line string?

d.text has the same problem; it solves it by redirecting input from
the temp file to which stdin is copied:

  max_buff = G_malloc(strlen(wind_file_name)+strlen(G_recreate_command())+4);
  sprintf(max_buff, "%s < %s", G_recreate_command(), wind_file_name);
  D_add_to_list(max_buff);
  G_free(max_buff);

However, d.mapgraph processes stdin directly, so you would have to
add code to store the data read from stdin (although you would have to
do this however you solved the problem).

Ultimately, the D_add_to_list() concept is fundamentally flawed. There
will always be cases which don't work.

--
Glynn Clements <glynn.clements@virgin.net>