Recently, I saw an article touting the use of Attention ID (AID) bytes, rather than response indicators, to process function keys. A very good idea--I use the AID byte myself.
However, there is another use of these AID bytes that the author did not mention: You can use them on your enhanced 5250 screens to process mouse button actions, such as double-clicking.
In this line of code, event and event2 identify the mouse button event. This is coded in the format *KBA, which is explained in the table below:
K = Keyboard State
B = Button
A = Action
U = Unshifted
L = Left
P = Pressed
S = Shifted
M = Middle
R = Released
| || |
R = Right
D = Double-Click
So *ULD would be left double-click, *SRP would be pressing the right button while holding the Shift key, and so forth.
When you execute a mouse event, an AID is returned to your program. This AID can be a function key AID. You code the function key like so:
This would return F4 to the program by setting the AID byte for F4 (x'34'). Coding the CF04 keyword in this case is not necessary (unless you do want to return an indicator).
However, you can return another type of AID: the event AID. The coding of this AID for MOUBTN is Exx, where xx is 00 thru 15:
The AID byte will contain x'70' through x'7F' for the corresponding Exx. So, E01 would return x'71' in the AID byte.
Event AIDs do not send data back to your program, behaving like CAnn keywords in this regard.
You can even return an AID for two mouse button events. For example, pressing the left button followed by pressing the right button can return one AID. This is known as a "two-event action." When you execute the first event, the AID (and control) will not be returned to your program until you execute the second event. (Things can happen that interrupt this, but we won't get into them now).
Where Is the Mouse Cursor?
When you execute a mouse event, the 5250 cursor will go to wherever the mouse pointer cursor is. You can use the RTNCSRLOC DSPF keyword to tell you where the cursor ends up as a result of a mouse action. RTNCSRLOC can also tell you where the cursor was at the start of a two-event action and where it was at the end of the two-event action. Here's the format:
What to Use Mouse Events For
- I return CF04 for a *URP event. If my users want to prompt an entry field, they simply right-click on the field they want prompted. Because I am using CF04, they can press F4 as well. In either case, the AID byte will contain x'34', and I will process F4 regardless of how the user activated it.
- On a prompt subfile, I can use *ULD to allow the user to select the prompt value. Since the mouse action puts the 5250 cursor in the mouse pointer's spot on the screen, I can use SFLCSRRRN to tell me which subfile record the user clicked on.
- On a subfile with options (such as 5=WorkWith, etc.), I use *ULD to assign an option. Usually, I use SFLCSRRRN to get the user's double-clicked subfile record, as described above, and I update it with the option. Often, I use *URD with a second option. On a recent application I wrote, I used *ULD for 5=WorkWith to drill down to the next-level subfile, and *URD for 9=Detail to proceed to the full detail screen (i.e., all the fields from the database record referred to by the subfile record).
I've thought about using *SRP for Help, *UMP for PageDown, and *SMP for PageUp. As for two-event actions, they lend themselves to drag-and-drop operations.
The possibilities are endless. Click away!
Doug Eckersley is the iSeries programmer with a premier homebuilder in Columbus. He has been programming on the iSeries for over 10 years and has been in the business for 15. He is certified by IBM.