MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » January 2014

RE: Common Display File (Header + File-level Keywords)



fixed

Thanks for the explanation. In this scenario, is there a way to set the file-level keywords and available function keys in one file and use them across the whole application, or do their definitions need to be present in each display file? Is there some way to set these with RPG or do they have to be compiled in with the DDS?

Thanks,
Sarah


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan Kimmel
Sent: Wednesday, January 29, 2014 2:52 PM
To: Midrange Systems Technical Discussion
Subject: RE: Common Display File (Header + File-level Keywords)

The best I've ever been able to do to accomplish what you're trying to do, is to divide each "working section" of the screen into a separate display file with its own program and overlay the screens. So I have Program A that calls program B to clear the screen and display header and footer sections and then calls one of several programs in some order that overlay the middle section with perhaps a subfile or other entry form. Those programs restore the screen and return information to Program A. Program A records the information and determines which program to call for the next "subscreen". Also use "popup" screens for choosing one of many values, for instance; one can reuse the same program and display file for many kinds of lists.

You can also accomplish the same thing with many "records" in a display file managed by a single program.

The old rule was one display file per program, but newer versions of RPG allow a display file per sub-procedure.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Sarah Kemp
Sent: Wednesday, January 29, 2014 10:06 AM
To: Midrange Systems Technical Discussion
Subject: RE: Common Display File (Header + File-level Keywords)

It's true I'm coming from a web background. I can't remember the last
time I made a page that was actually all located in one file so I am
trying to get these green screens working with the same flexibility.
I'm looking for a combination of CSS and a PHP (or ASP) 'include',
which just grabs the header file (which could have standard config,
output, and style information) and adds it to the page. I am ok with
this 'grab' being at compile time rather than runtime, but I really
don't like the idea of just having a template that I copy and paste into each new screen... what if something changes?

I'm really struggling with the limitations of DDS. I did see this preprocessor:
http://rpglanguage.biz/copybook.html. Not being very familiar with
iSeries terminology, it sounds like it might be capable of allowing a /COPY in my DDS.
Has anyone had any experience with something like this?

Thanks,
Sarah


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, January 29, 2014 6:13 AM
To: Midrange Systems Technical Discussion
Subject: RE: Common Display File (Header + File-level Keywords)

Sounds like she's trying to do a DDS version of Cascading Style Sheets (CSS).


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Alan Cassidy <ACassidy@xxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 01/29/2014 08:58 AM
Subject: RE: Common Display File (Header + File-level Keywords)
Sent by: midrange-l-bounces@xxxxxxxxxxxx



....If I use a WRITE header followed by an EXFMT main screen, only the
main screen is displayed and none of the file-level keywords from the
header are active.

Use the OVERLAY keyword on the EXFMT screen, and watch your header
record
remain:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frzak
c%2Frzakcmstoverla.htm


I have also seen advice to designate a header field in your display file
and customize it in your program in order to allow a more standardized
header, but I don't know how (or if) it can be used with file-level
keywords and allowed function keys?

Probably header fields (plural). Most of mine show a file/screen name
upper left, application name in the middle, date and time upper right, a
subtitle on the 2nd line centered. Go by shop standards, and/or clone
somebody's DDS code and customize to your specifications.

If this is not possible, how is screen standardization usually handled?

Shops vary on this one, but almost all of them are pretty definite about
that. If they don't seem to, or it's a tiny shop, they might not, in which
case I have usually simply tried to find what most of the screens already
look like to the users and take it from there.

(Would that more shops were pushing for Web interfaces)..

Alan Cassidy

At Caledonia Financial Services
acassidy@xxxxxxxxxxxxxx
954-693-0000 ext. 3433 - Direct phone
786-380-9236 - Mobile phone



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Sarah Kemp
Sent: Tuesday, January 28, 2014 5:38 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Common Display File (Header + File-level Keywords)

I learning about RPG and DDS for screens and I am trying to determine if
there is some method of including or referencing one DDS screen inside of
another. What I want to be able to do is create a "common" display file
that has, for instance, the company name and the date, and includes some
file-level keywords and allowed function keys (INDARA, CA03, etc.). Then,
ideally, I would be able to create program-specific screen content in a
separate file without having to redefine the common function keys, header
information, and file-level keywords.

Is there a method of including DDS source with something like a /copy? Or
can I use two display files in one RPG program and have their allowed keys
and keywords both active at the same time? I have tried using two in one
program, but I can only get them both to display by using EXFMT rather
than WRITE for the header file, which means control needs to be returned
before the main screen is written. If I use a WRITE header followed by an
EXFMT main screen, only the main screen is displayed and none of the
file-level keywords from the header are active.

I have also seen advice to designate a header field in your display file
and customize it in your program in order to allow a more standardized
header, but I don't know how (or if) it can be used with file-level
keywords and allowed function keys?

If this is not possible, how is screen standardization usually handled?

Thank you,
Sarah
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a
moment to review the archives at http://archive.midrange.com/midrange-l.


--------------------------------------------------------------------------------
Confidentiality Notice: This email may contain confidential information or
information covered under the Privacy Act, 5 USC 552(a), and/or the Health
Insurance Portability and Accountability Act (PL 104-191) and its various
implementing regulations and must be protected in accordance with those
provisions. It contains information that is legally privileged,
confidential or otherwise protected from use or disclosure. This e-mail
message, including any attachments, is for the sole use of the intended
recipient(s). Any unauthorized review, use, disclosure or distribution is
prohibited. You, the recipient, are obligated to maintain it in a safe,
secure and confidential manner. If you are not the intended recipient,
please contact the sender by reply e-mail and destroy all copies of the
original message. Thank you.
--------------------------------------------------------------------------------


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.








Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact