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



Francois:

Thanks for your comments. I am actually trying to achieve this using ONLY
the DSM API set, no DDS at all. This is because you can always create the
actual display screen by hand (although tedious of course) and then I'll
try to combine the different input operations. All of what I've been
reading on this subject doesn't tell me anything about how to connect DDS
with DSM API's but I bet it's possible.

Since there is no DDS, you have to construct a low-level environment where
all the parameters like the INVITE keyword equivalent and also the time-out
value are set with the QsnCrtEnv (Create Low-level Environment) API.

I've been dealing with the DSM documentation, but this is barely the API
prototypes and the several data structures and constant values that these
use. There are no significant examples and what I've found on the Web is
also poor material. I'll have to wrap up my sleeves and try.

What I've read until now is that the QsnReadInvited API has to be issued in
combination with another AID-generating input Read. So that when the
latter Read fails and times-out, it's the former which informs the
timeout. Since the input buffer is still there, that's the right moment to
invoke the *QsnReadImm* API which is a non-AID-generating read input from
the screen, and that should probably bring me the data that I'm expecting:
the one the user may have typed in.

I'm still writing a test program to do that. I will share with you guys my
results.

Thank you Jon Paris also for your recent comments about the subject.
Regards.



message: 1
date: Wed, 11 Aug 2021 17:26:23 +0000
from: Francois Lavoie <Francois.Lavoie@xxxxxxxxxxxxxxxxxxxx>
subject: RE: Using a timeout with display files

DDS manual says:
" On a read operation from invited devices operation to a display file,
only data from devices with an
outstanding invite operation are considered. The input operation waits for
data from any of the invited
devices. (See the WAITRCD parameter on the Create Display File (CRTDSPF)
and Change Display File
(CHGDSPF) commands.) If none of the invited devices responds before the
wait time ends, a notify
message is sent and no data is returned."

So, no data is returned when the notify message (Status=1331) is sent

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

message: 3
date: Wed, 11 Aug 2021 17:46:20 +0000
from: Francois Lavoie <Francois.Lavoie@xxxxxxxxxxxxxxxxxxxx>
subject: RE: Using a timeout with display files

Maybe if you put an indicator on the INVITE keyword
You 1st set it ON, then READ dspf
If timing out (Status-1331) then you set INVITE indicator OFF and re-READ
dspf
*Maybe* (didn?t test it) that would return any data typed by the user




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.