Re: How to use the DSM QsnSetCsrAdr API?

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