Re: window in a window and stupid DDS tricks

Joel,

Resist the urge to "over think" the situation.  Is your background COBOL? ... 
;-)

Just for basics, put a "ASSUME" record in your display file template and get 
over
it.  It's like comments, every file/program has them ... don't they?

Basically it depends on if you want one of two scenarios: 1 display file for 
each
program or 1 display file for all programs.
Well not "all" programs, but all programs within a logical function.

For example, our shop, like most, have chosen a "lesser" evil approach.  Now
every shop picks their own "lesser evil", but in our case we opted for a single
display file, with shared open, RSTDSP(*NO) and separate programs for each verb.

Lets say "Customer".  So we have CUSTWRK (we follow the IBM guideline of
subject/verb to avoid conflict of OS verb/subject syntax) and CUSTADD, CUSTINQ,
CUSTEDT, CUSTLST, CUSTPRG, CUSTRGZ, etc. and with all of that we have CUSTDSPF
(along with CUSTPRTF).

We also have a shop standard for display presentation:

lines 1&2 contain user/job/date/time/command/title/action text
lines 3 thru 7 to 9 are subfile control
lines 8 or 10 thru 20 are subfile
line 21 is "more.." or "bottom"
line 22 & 23 are command keys
line 24 is ERRMSG subfile

There is (of course) the exception where lines 8 or 10 thru 19 are the subfile
and line 20 is a footer.  As in your case of wanting a constant total displayed
within a scrollable screen.  It is not -necessary- that this be done with a
window.  IMHO, that just adds another layer of complication.

We use this approach with Open Receivables/Payables/Sales Orders/Purchase
Orders/drill down/ etc. where the request is in the subfile control record (on
top), the detail (scrollable) is in the middle and the result is at the bottom.

To do this, we have one record that clears 23 lines (leaves messages .. separate
function clears messages) and places lines 1&2 with a WRITE, we then WRITE the
command keys (oh, did I mention all display files use DFRWRT(*YES)?), build the
subfile, obtain total, WRITE total(footer), EXFMT subfile.  All formats use
OVERLAY.  Sort of like comments, most have them.

Now, should the user select a certain function, it may be displayed in a window.
Like if the program asks for a customer number and the user presses F4, a search
window appears and the results appears in a separate window with "1=Select
5=Display" choices and the select program may or may not turn on LR and to get
the border to display on the second request you may have to do a display of a
"record", yadda, yadda, yadda.

Through some experimenting of inter program behavior you can create a
"caller/called" template which will avoid screen flicker, retain borders and 
give
a green screen a "windows" appearance.  The long term benefit will be through
standardization, transition to a new presentation method (JAVA/VB) can be solved
programmatically vs brute force.

Hang in there, our way is not the only way nor is there a "right" way.
FlameSuit(*ON) ;-)

IMHO, any standard, enforced, is a good standard.

James W. Kilgore
email@James-W-Kilgore.com



Joel Fritz wrote:

> I've learned a lot by exposing my ignorance.
>
> Now I can put a window in a window without using the ASSUME keyword,
> providing it's a one display file, one program situation.  Calling another
> program that pops up the window in a separate display file is a different
> issue.
>
> I never realized you could put the subfile control record below the subfile.
> Unfortunately, what I'd really like to do is have part of it above (colum
> headings and so forth) and part below (totals, function keys.)
>
> Could someone enlighten me on the window footer record.  The only reference
> I could find (using Info Seeker, admittedly) in the DDS and Display
> Programming manuals (v3r7) was a note in an appendix to the Display
> Programming manual that Rumba doesn't support them. It's not the window
> title, is it?
>

<<snip>>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---