|
I like most of this post. I did try the DSPATR(&VARNAME) technique but i stoped because the "position cursor" attribute is not supported (must be set by an indicators). Since we use this a lot here (to position the cursor on the first error encounterd on the screen) and that we did not want to use different technique for different attribute, we setteled on using indicators for display attribute (but giving them meaningfull name). I also want to stress that using the display file data structure to find out the pressed key is the way to go. this way, all keys can be treated the same way (function keys, page up/down, print screen, even enter). Denis Robitaille Directeur services technique TI 819 363 6130 SUPPORT Jour (EST) Daytime : 819-363-6134 En-dehors des heures (EST) After hour : 819-363-6158 Network Status : 819-363-6157 >>> CWilt@xxxxxxxxxxxx 2006-01-12 14:29:08 >>> I'm afraid you'd be shot for that here. <grin> What's the use of having a long name if you don't use it? If you want to group them, fine....but only in order to set/reset them all at once. Using a big long string to set some off and some on wouldn't fly. Here's an example: d gDisplayFileControl... d ds qualified d FunctionKeys n overlay(gDisplayFileControl : 1) d dim(24) d exit n overlay(gDisplayFileControl : 3) d printList n overlay(gDisplayFileControl : 5) d cancel n overlay(gDisplayFileControl : 12) d PageUpDown n overlay(gDisplayFileControl : 25) d dim(2) d pagedown n overlay(gDisplayFileControl : 25) d pageup n overlay(gDisplayFileControl : 26) d ReverseImage n overlay(gDisplayFileControl : 51) d dim(10) d RI_PartNbr n overlay(gDisplayFileControl : 51) d RI_Desc n overlay(gDisplayFileControl : 52) d RI_VendNbr n overlay(gDisplayFileControl : 53) d RI_AcctNbr n overlay(gDisplayFileControl : 54) d RI_UOM n overlay(gDisplayFileControl : 55) d RI_Class n overlay(gDisplayFileControl : 56) d RI_Plant n overlay(gDisplayFileControl : 57) d RI_Import n overlay(gDisplayFileControl : 58) d RI_DrawCd n overlay(gDisplayFileControl : 59) d RI_Spec n overlay(gDisplayFileControl : 60) In addition, note that you can use the file data structure to find out what key has been pressed instead on using indicators. Also, you can use the DSPATR(&VARNAME) to control field attributes. The only need for indicators in a display file is for certain keywords, like SFLCLR, that need them. HTH, Charles Wilt -- iSeries Systems Administrator / Developer Mitsubishi Electric Automotive America ph: 513-573-4343 fax: 513-398-1121 > -----Original Message----- > From: rpg400-l-bounces@xxxxxxxxxxxx > [ <mailto:rpg400-l-bounces@xxxxxxxxxxxx> > mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Weber, Richard > Sent: Thursday, January 12, 2006 2:11 PM > To: 'rpg400-l@xxxxxxxxxxxx' > Subject: Indicator Coding Technique > > We are developing a set of Free Form RPG coding standards. > (Yes, now. We > are primarily a COBOL shop just moving over to RPG, stepping > boldly into the > 1980's!) I want to get the opinion of the group on a > technique for setting > DSPF indicators that was proposed. > > > > The proposal was to code a data structure for the screen > indicators using > the "N" data type and to use variable names that are meaningful. The > technique that I am asking for opinions on is that the group > of indicators > can be set or tested by using a string such as: '0010000000100000000". > > > > I am intentionally not stating my opinion, so as not to affect your > comments. Thanks for your input. Code snips follow. The > purpose of this > code it to control which functions keys are available when the screen > displays: > > > > D DspFInd DS > > D FunctionKey 1 24 > > D PageDown 25 25N > > D Request 28 30 > > . > > . > > . > > BEGSR $S0Display; > > Request = '100' ; > > FunctionKey = '001000000001000000000000' ; > > EXSR $SZGET; > > EXSR $S1DspFmt; > > ENDSR; > > > > > > Richard L. Weber | Senior Systems Analyst, TOYS '*' US > International | > 973.617.3497 | weberr@xxxxxxxxxxx < <mailto:weberr@xxxxxxxxxxx> > mailto:weberr@xxxxxxxxxxx> > > > > > ============================================================== > ========== > This email message is for the sole use of the intended > recipient (s) and may > contain confidential and privileged information. Any > unauthorized review, > use, disclosure or distribution is prohibited. If you are not > the intended > recipient, please contact the sender by reply email and > destroy all copies > of the original message. To reply to our email administrator > directly, send > an email to EmailAdmin@xxxxxxxxxxxx > Toys "R" Us, Inc. > -- > 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> > 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> > http://archive.midrange.com/rpg400-l. > >
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
