× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Interesting.  I just might give it a go next time I do a subfile.

Ron Power
Programmer
Information Services
City Of St. John's, NL
P.O. Box 908
St. John's, NL
A1C 5M2
Tel: 709-576-8132
Email: rpower@xxxxxxxxxx
Website: http://www.stjohns.ca/
___________________________________________________________________________
Success is going from failure to failure without a loss of enthusiasm. - 
Sir Winston Churchill




"Larry" <Larry_Ducie@xxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
02/12/2004 08:02 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
<rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: Subfile question






Hi Don,

<snip>
I've wondered about that many times over the years.  Paul's assertion that
setting SFLSIZ and SFLPAG to be identical will make it work makes me 
wonder
what is special about that condition.  If it works for one subfile page, 
why
not more? 
</snip>

I believe the point of a "field selection subfile" is to mimic a panel. I
have written several such subfiles to run in our applications, but I've
never used one in a way that allows you to page-up or page-down. They have
always been used for field selection panels. That's why pageup and 
pagedown
are disabled. That's also why you specify that your complete subfile will
fit on a single page - it's a panel.

Think of this scenario: We have a generic screen that is used to allow 
users
to enter selection criteria for submission of various reports. The same
screen is used for ALL of our reports. Consequently, there are MANY fields
that the user can possibly input data into. Now, most of these fields are
optional. That is, they will be displayed for some reports but not for
others. Logically you condition these fields on indicators and display the
ones you need for a particular report.

The two big problems with this are:

1) You quickly run out of space to fit fields in your panel.
2) As most reports will use only some of these fields, you end up with big
"holes" in your entry screen.

This is very annoying, especially if you have a report that only takes 
four
values and they're spread all over the screen because that was the only
space left in an already cluttered panel. 

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!

So, it's a myth that you can't generate a subfile with each line having
different fields to the other lines. It's actually quite easy. The only
downside is that you have to handle a lot more when processing the records
in the subfile - you need to know which of the possible n fields on your
current record is actually enabled. If you use paging you have to rebuild
your subfile from scratch each time - it can only fit on one page after 
all.
This is usually done using arrays and "windowing" your subfile up and down
the array.

I must say that we use these "panels" more and more. Once you've written 
one
you will never look back! They look so clean, and every selection panel 
has
a similar look-and-feel to every other related selection panel - usually
because most of the time they are actually the same panel!

Give it a go.

Cheers

Larry


--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.