|
On Thu, 12 Jan 2006, Denis Robitaille wrote:
I did try the DSPATR(&VARNAME) technique but i stoped because the "position cursor" attribute is not supported (must be set by an indicators). Since we use this a lot here (to position the cursor on the first error encounterd on the screen) and that we did not want to use different technique for different attribute, we setteled on using indicators for display attribute (but giving them meaningfull name).
You could use CSRLOC to set the cursor position rather than DSPATR(PC). That'd eliminate the need for an indicator.
When you use DSPATR(&VAR), what you're really doing is setting VAR to have the exact 5250 code that you want to send to the display. However, "position cursor" isn't really a display attribute. There's no 5250 attribute value for position cursor, so there's no value you could possibly put into &VAR that it could send to the terminal.
It's quite curious that IBM made DSPATR(PC) a display attribute in the first place. Why didn't they have a "POSCSRFLD" keyword or something like that? Why DSPATR? it has little to do with how the field is displayed.
This whole DSPATR(&VAR) thing was very poorly done, IMHO. People coding DDS want a level of abstraction between their code and the 5250 data stream. They don't want to code raw 5250 codes. IBM could've easily written it so that you set var = 'HI BL', and had it be high intensity and blinking.. they didn't need you to pass the raw attribute code.
But anyway, complaining about something that was implemented a long time ago and isn't changable at this point, is really an exersize in futuility.
I also want to stress that using the display file data structure to find out the pressed key is the way to go. this way, all keys can be treated the same way (function keys, page up/down, print screen, even enter).
I have the same problem with that technique. We shouldn't have to work with the raw 5250 AID bytes, we should have some level of abstraction. It's a really poor design that our two options are hex codes vs. numeric indicators.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
