RE: Subfile question

["Fisher, Don" <Dfisher@xxxxxxxxxxxxxxxxx>]

I'm not certain how I would pull that off, especially considering I like to
include cursor sensitive help in my applications.  I also think one would
quickly run out of indicators in such a scenario, so I'd have to think about
this for a while.

I have a bunch of field selection screens that allow selection of multiple
values for a single field like "Location" for instance.  These screens also
allow selection of other values depending on the report so multiple subfiles
are used with an entry field or function key that can be used to display a
specific selection screen.  One of these days I'm going to figure out how to
turn the entry field into a drop-down box. 

Anyway, the point is that most of these screens are pretty complex things
that may not easily fit into the "build the screen on the fly" model, but
I'll think about it.

What would be really nice is if I could take the "Location" subfile and all
the associated code and encapsulate it instead of having to copy it into
every report submission screen, but that's another discussion. 

Thanks. 

Donald R. Fisher, III
Project Manager
Roomstore Furniture Company
(804) 784-7600 extension 2124
DFisher@xxxxxxxxxxxxx

<clip>
The answer??? Use a field selection subfile. This allows you to build your
panel dynamically. As all fields are added as you write your subfile
lines,you don't have any gaps in your screen. It builds from the top down.
When our report selection app is run, the fields are retrieved from a file
and
the selection screen is "custom built" for that report. If we add a new
field to filter on the report, it's added to the file and it appears on the
screen!
<clip>