|
On 13/01/2006, at 9:18 AM, Scott Klement wrote:
When you use DSPATR(&VAR), what you're really doing is setting VAR to havethe 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.
While I agree that the implementation of DSPATR(&VAR) could have been better it's not true to state that the content is a 5250 attribute value. That is only true for the non-protected field values. The values for protected fields do not match 5250 attribute bytes because they have the left-most bit on. Attribute bytes must have the first 3 bits set to 001. Setting the left-most bit to on makes this byte look more like a Field Control Word (FCW) byte but it's not because FCWs are two bytes. It also looks like an extended attribute byte but is not in the correct range for one of those.
DSPATR(&VAR) doesn't support any of the other non-attribute values either such as SP, OID, or MDT. However this is very odd because PR is not an attribute either but they chose to support that. PR is implemented by the Bypass bit in the Field Format Word (FFW) byte of the Start of Field order. MDT is implemented by the MDT bit in the FFW. SP and OID are implemented via FCWs. PC is implemented via the Insert Cursor or Move Cursor orders.
I would have thought that PC was of more use than the PR values so it's odd that they provided a second set of values for protected fields. As soon as the designed started creating separate sets for different classes of attribute he/she should have realised they were on the wrong path.
PC, PR, SP, OID, and MDT should have been implemented via a different keyword. I don't have any real problem with IBM expecting the 5250 attribute values for DSPATR(&VAR) because a decent set of named constants takes care of the ugliness. Constants can be ORed to create composite values and the code is still self-documenting.
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. numericindicators.
While it would be nice to have symbolic constants for the AID byte values that would be an RPG specific extension and I'd rather see the compiler writers provide new function that I cannot do myself than have them provide different methods of accomplishing the same thing--especially when a decent set of named constants avoids me having to deal with the 5250 values directly.
The real problem with symbolic constants for the fields in the INFDS/PSDS is where to stop? You want AID byte symbolic values, someone else will want file type symbolic values, someone else again will want symbolic values for the miscellaneous flags especially since they are bit values. The compiler writers only do 10 or so (*FILE, *STATUS, *OPCODE, etc.). I really don't want them wasting time on this when a decent set of constants will handle symbolic values.
Thank goodness they've caught up with providing BIF versions of all the fixed-form op-codes so maybe now they can concentrate on new function (like overloaded procedures, name spaces, etc.)
I too agree that a DDS keyword for position the cursor is needed. CSRLOC is too primitive. It requires me to do the field to row/col mapping. What is needed is the opposite of RTNCSRLOC that would allow record/field/position to be specified. The *WINDOW|*MOUSE version would be useful for output too. Call it SETCSRLOC. You'd have to do a DCR for this feature and it would be against Rochester because as far as I know they own the DDS compiler.
However I doubt much if any work will happen to make DDS display file processing any easier. Shouldn't we all be using Java for display output therefore client/server applications?
Regards, Simon Coulter. -------------------------------------------------------------------- FlyByNight Software AS/400 Technical Specialists http://www.flybynight.com.au/ Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\ Fax: +61 3 9419 0175 \ / X ASCII Ribbon campaign against HTML E-Mail / \ --------------------------------------------------------------------
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
