RE: How to use the DSM QsnSetCsrAdr API?

You can just a easily get that information from the QUSLFLD API if your
screens do not contain two screens sizes where fields are defined in
different locations.



Thanks, Matt

-----Original Message-----
From: M. Lazarus [mailto:mlazarus@xxxxxxxx]
Sent: Wednesday, January 21, 2009 6:21 PM
To: RPG programming on the IBM i / System i
Subject: Re: How to use the DSM QsnSetCsrAdr API?

Doug,

You've hit the nail on the head. I've used that API before and
it's quite nasty. Are you at liberty to share the code for the
RtvFldLoc() routine?

-mark

At 1/21/09 06:22 PM, you wrote:

Mark,

Recovery . . . : Specify a field ID that is defined through the

QsnSetFld

API and try the request again.
__________________________________

Does that mean that the entire screen must be generated via
DSM? Or can I retrofit this in combination with standard DDS?

When you use QsnSetFld you use the Field ID *or* the row and column but
never both (either *OMIT the others or pass zeros). However, the field

ID

is a concept that only exists within the DSM apis for your convienence

in

creating dynamic displays. When you add fields using QsnSetFld you can
specify any unique non-zero value as a field ID (they do not need to be
consecutive) and the DSM apis remember it and allow you to use it in

other

APIs in lieu of the row/col pair.

However, it is not part of the 5250 data stream, nor does the WS

controller

format have any concept of any field IDs. Unless you are using

DSPATR(PC)

in the DDS, the only alternative is to ultimately set the row/col

values.

And at that point you may just as well use the DDS keyword CSRLOC

instead of

bothering with QsnSetCsrAdr().

However, that does not necessarily mean you need to hard code the

row/col

pairs. What I did was create a service program routine RtvFldLoc()

which

accepts a display file, format, and field name and optionally the mode,

then

uses the QDFRTVFD api to retrieve that field's screen location at

runtime.

Then I just pass those to the variables used with CSRLOC() keyword in

the

display file. The service program routine caches the last used values

for

the display file and format so it can minimize the overhead of

populating

the user space. Performance is fine.

But QDFRTVFD is not the simplest API around. If you haven't used it

before,

Google for examples.

Doug