One option would be to modify kpg1_gtgrp so that, before exiting, it
concatenates all the elements in the returned group into a single
comma-delimited string, and stores this string as the current value of
the parameter. This is a bit like what kpg1_gtgrp already does, except
that currently it only concatenates values supplied via multiple
prompts (each ending with a minus sign). But there are two practical
issues with this dea:
1) I wrote kpg1_gtgtp 11 years ago, so I can't remember the details,
but I *do* remember that finding a way to set the current value of a
"READ" parameter was difficult. And indeed, now I try it in practice,
it seems not to work :-( That is, if you split up a group expression
over (say) two prompts by ending the first prompt value with a minus
sign, and then examine the contents of the application parameter file,
you see that the current parameter value only hold the final prompt
value, not the concatenation of all values. Still, there must surely
be some way of setting the current value of a READ parameter from
within a program (kpg1_gtgrp currently uses subpar_putname).
2) The contents of a file can be arbitrarily long, so I'd not be
surprised if concatenating all the contents of a file into a single
string and storing it as the current parameter value did not trigger
some problem within subpar such as filling of fixed-sized buffers etc.
And then it could lead to huge bloat in the history text which may
often not be what you want in all cases.
Still, I could look further into whether this option is doable or not.
David
2009/10/5 Tim Jenness <[log in to unmask]>:
> In SMURF some of the commands use big config files that are read using
> kpg1Kymap and kpg1Gtgrp. The main problem we have is that the HISTORY
> written out simply reports the name of the config file (with a "^") and not
> its contentns. Usually the name is irrelevant and the contents are
> important. I'm wondering whether anyone has ideas for a general solution to
> this problem (maybe in NDF or KAPLIBS) before embarking on some
> smurf-specific hack for dumping the AST keymap into an additional history
> record (or even dumping the whole thing in a SMURF extension). There are
> many places where this sort of thing would be useful (I'm thinking of IN/OUT
> parameters that read a GRP file but then don't write the filenames into the
> parameters). Recognizing GRP inputs automatically would be really useful.
>
> --
> Tim Jenness
> Joint Astronomy Centre
>
|