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



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



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.