× 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.



CSRLOC should be defined on theSFLCTL level, not on the SFL.

With regards,
Carel Teijgeler


*********** REPLY SEPARATOR ***********

On 22-7-2009 at 14:45 Robert Nesiba wrote:

Booth,
I see where CSRLOC is not valid for SFL record format.
I also tried adding those 3 lines to my SFLCTL record,
and my DDS won't compile there either.

Any other ideas?
Thanks, Bob Nesiba


The CSRLOC keyword is not valid for the following record formats:

* Subfile record formats (identified by the SFL keyword)
* User-defined record formats (identified by the USRDFN keyword)


Booth Martin wrote:
This should work for you:

"CSRLOC (Cursor Location) keyword for display files

You use this record-level keyword to specify the cursor location on an
output operation to the record format that you are defining. Your
program sends the output operation after setting the cursor location.
...
Example

The following example shows how to specify the CSRLOC keyword.


|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+
....8
00010A R RECORD1 CSRLOC(LINNBR POSNBR)
00020A TITLE 40 B 1 2
00030A PAGE 5Y OB 1 60
00040A TEXT 1760 B 2 1
00050A LINNBR 3 OH
00060A POSNBR 3 OH

"


http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzah
g/icmain.htm

Setg the LINNBR & POSNBR as a constant for the position you want for the

first subfile option field.


Robert Nesiba wrote:

Thanks all & especially Booth.

FLDCSRPRG works on a regular display panel, but
SFLCSRPRG is what we were looking for to move from record to record on
our subfile.

Only odd behavior is that after tabbing down (like we want),
one additional tab keystroke moves the cursor to the other input
capable
field (amount field)
on the last record of the subfile. Why there?
A second additional tab positions the cursor at the first option field
(the field where we want it).

Is there a way to prevent it from tabbing over to that second input
field?
Our user may inadvertently change the amount if the cursor is
accidentally positioned there.

Second question: can I easily re-position the cursor to the first
subfile record on page up/page down?

Thanks much!


Booth Martin wrote:


"SFLCSRPR G (Subfile Cursor Progression) keyword for display files

You use this field-level keyword to define that when the cursor leaves

the field, it goes to the same field in the next subfile record
instead
of the next field in the same record."

http://tinyurl.com/2tv96d*
*

See if that does the trick for you.*
*


Robert Nesiba wrote:



We have a _subfile_ with two input fields, an option field and an
amount
field.
We want the cursor to progress down to the next option field, not
across
to the amount field.
It would be just fine if the amount field would only position-to
when the user specifically uses the arrow keys to position to it.
(Rarely used)
What is the simplest way to accomplish this? Is there a DDS only
keyword method?
(We prefer to not use a function key to toggle the amount field
between
input allowed and protected)

Thanks, Bob



------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.387 / Virus Database: 270.13.21/2252 - Release Date:
07/21/09 05:58:00










------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.387 / Virus Database: 270.13.22/2253 - Release Date:
07/21/09 18:02:00






--
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.


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.23/2254 - Release Date: 07/22/09
05:59:00




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.