Passed parameters and selection sets

[Ray Scheel]

> -----Original Message-----
> On Tuesday, August 02, 2005 2:00 PM Nancy Palmquist wrote:
> Ray Scheel wrote:
> > I would enter and save a selection set like this:
> > a      |  5  | unitcd ; unit code      eqf|   @pm|
> > b      |  @pm| Parameter               eq |   _|
> > |
> > c      |  @pm| Parameter               eq |   _|
> > |
> > Selector Sentence:
> > a or (b and north) or (c and south)
 
> First if you are assigning the value with -r on a command 
> line, you can 
> use that information in the processing and remove or select 
> as required.

That is exactly what I ended up doing in logic very similar to what you
provided.  I am mainly aggravated that the selection set screen
truncated the values I entered and didn't bother to let me know it had
done so until I returned to it trying to figure out why my selection
processing was acting bizarrely for the leading "_" parameters.  I don't
see any reason for that limitation, especially since it appears other
system fields do not display that behavior.  

> On this selection table, I see no group called north or south so your 
> selector sentence is not going to work.
> How can the unit code be the same thing as the north/south thing?

The "north", "south" etc are other -s selection sets, listing particular
unit codes.  Handling the details in sort/select(-v) processing, I
removed line "c" from the set with a selector sentence of "a or b"  No
unit code starts with an "_" (nor will a future code) so I matched on a
leading "_" or a full match to the unit code to select in the -s set (so
I'd still have a faster select for just a single unit selection) and
sorted the rest out in -v processing.

> Just create a scan/select table, pick up the values of @pm, @py, @pw 
> etc. and select in that method.  Using a selection table in 
> this way is 
> an unconventional solution to this problem.  I am not sure, 
> but I have 
> never seen anyone try to do it just that way.

I've been hacking fP code full time for a bit less than 6 years, and a
few years of poking at it before then, so I'm still towards the "new"
end of the fP curve.  I've learned fP with a lot of features available
"standard" that the more experienced hands have only recently gotten
used to having available at all.  What I'm learning the hard way is that
the newer features are often not reliable unless used in a particular
way designed to help with a challenge in how things have "always" been
done, but really haven't been tested in some of the other ways they
*could* be used.  

My goal was to create a re-usable chunk of selection at the -s level so
I could avoid having to slurp in the same code into multiple -v tables
for the relatively straightforward task of limiting the records we are
looking at to particular unit(s).  We are moving more and more of our
reporting to a web presentation, and thus are relying more on passed
values to gather data at the front end we would have previously snagged
within an interactive -v process run after the -s selection had already
been completed.  I've started down that route of anyway, but its a
missed opportunity to not have the contents of the passed parameters
available for comparison to a fixed value in a -s selection set.

Ray Scheel