Back to Basics: Side-by-Side Subfiles
by Kevin Vandever
[The code for this article is available for download.]
In the article "Back to Basics: Multiple Subfiles on One Screen," I discussed placing more than one subfile on a screen by using the over/under technique, which is coding one subfile over or under another. This is a cool way to display multiple lists on a screen. But you want more, right? You want to know how to display multiple lists on a screen, side by side. Well come on in, and I'll show you how to do just that.
Impossible, You Say?
Before I continue, let me just say that subfiles cannot reside side by side on the same screen. Now, before you hit Send on that flaming e-mail you're about to send me, let me explain. When you define DDS for a screen that will include a subfile, you have to concern yourself with what row you are defining for each record format. What I mean is that, in a typical subfile layout, you have the subfile control record that takes up the top three or four rows of the screen. It could be more, it could be less, but, generally, the top portion of the screen is the subfile control, or header, portion. By the way, you can just as easily reserve the bottom portion of the screen for the subfile control. It doesn't have to display above the subfile record format; it just can't overlap it. Anyway, once you have defined which rows the subfile control record will consume, you define the subfile record format. This is typically the middle part of the screen and cannot overlap the subfile control record. So, if your subfile control header takes up rows 1 through 4, your subfile record format must start on row 5. Last, you usually display some sort of function key line, and maybe a message line, at the bottom of your screen. Again, these lines cannot share the rows occupied by the subfile record format. Once you've defined the rows that each format will occupy, these formats occupy every column in their respective rows. You cannot have the subfile record format occupying only columns 1 through 40. Even if the actual fields you define in subfile record only take up 40 columns, the format itself consumes all the columns in a particular row on the screen. So have I wasted your time by having you read this far, only to find out that side-by-side subfiles are impossible to create? No!
My secret method for displaying subfiles side by side is to use windows (OS/400, not Microsoft). The good news is that you can place windows side by side on a screen just fine. So if each of those windows happens to be a subfile window, you are now able to place subfiles side by side. The bad news is that, since these subfiles are separate windows, they cannot be active at the same time. You can display up to 12 windows on a screen at one time, but only one can be active. However, I don't give up easily, and neither should you. I will show you a technique to make the side-by-side windowed subfiles appear as two active subfiles on one screen.
Nothing Up My Sleeves
For this technique, I am going to use two load-all subfile windows and place them next to each other on the screen. The DDS, SDBYSDDF, will include a header, a footer, and two subfile windows. I got really tricky this time and did not display the same data in each subfile, as I did in my previous article explaining the over/under technique. The first subfile will contain first names and middle initials, and the second will contain last names. (I did not include the physical file SFL001PF, which is referenced in the DDS. I figured you could create your own DDS containing the three fields used in my example.)
Consider this application as a way to see how different combinations of first and last names look together. In my example, I really don't want to show the user that I am displaying two separate windows, so I am going to explicitly define the window border as blanks. Remember that the WDWBORDER keyword is optional, but if you leave it out you will get IBM's default border. In this case, I want no border, so I am going to add a WDWBORDER keyword to define no border. You can see that the windows are defined pretty much the same by looking at the WINDOW keyword entries in each subfile control format. The only difference is the third parameter. That parameter tells where to place (by column number) the upper right-hand corner of the window. They have been defined appropriately to place the windows side by side.
Another technique I like to use with side-by-side windows is the USRRSTDSP keyword. USRRSTDSP allows you, not OS/400, to control when your windows are saved and restored. By using USRRSTDSP in the second window, OS/400 will not save the first window when the second window is written. That's not such a big deal to us in this example. However, USRRSTDSP also causes the second window not to be removed when the first window is written again, and, conversely, the first window is not removed when the user toggles back to the second window. So by using a function key (in my example F9)--to toggle back and forth between windows--and the USRRSTDSP keyword, I can make it look as though both windows are active at the same time. The side-by-side technique still works without the USRRSTDSP keyword, but you will see a big difference when you toggle back and forth. Without USRRSTDSP, the windows will be removed and restored, which will cause the screen to "flash" each time the toggle (F9) key is pressed. By adding USRRSTDSP to the second subfile control record, the "flash" will disappear and you will only notice cursor movement between the two windows. Try running the programs both ways to see what I'm talking about.
The Toggle Technique
Check out the RPG program, SDBYSDRG. As usual, the RPG doesn't get to have much fun where subfiles are concerned. The DDS primarily controls what's going to happen. However, there are a few things that I want to show you in the RPG that are a bit different from what you may have done before. The field WHICH_ONE will be used to determine which subfile window to control. As the user presses F9 to toggle between windows, the WHICH_ONE field will be set to a 1 or a 2. In my DOU loop, which processes the screen, after I write my HEADER and FOOTER formats, I display both windows but will determine which one is active based on the WHICH_ONE field. Since I initialized it to 1 in my D-specs, the first time through the loop, the window on the left side will be active. When the F9 toggle key is pressed, I determine the value of WHICH_ONE. If it is 1, I change it to 2; otherwise, I change it back to 1. At the next iteration through the DOU loop, the value of WHICH_ONE is interrogated to determine which window to make active. You may also notice something else in the toggle logic. As I determine which window is currently active, so that I can toggle to the other window, I also set the RRN associated with the window that will become active. The sflrrn definition in D-specs provides you with another little trick to control side-by-side subfile windows. If you go back to the DDS, you will notice that I used the SFLRCDNBR keyword and associated it with the relative record number in each subfile record. SFLRCDNBR allows you to display a given page of the subfile based on the current relative record number. Now back to the RPG and the sflrrn D-spec. This information comes from the file information data structure. In addition to the indicator that tells me what key the user pressed, I am also going to retrieve the relative record number of the first subfile record on the page from the file information data structure. What this allows me to do is remember what page was displayed when the user pressed the toggle key to go to the next subfile. When he toggles back, I want the subfile to stay in the same place it was when he left. So, in my toggle logic, I not only set WHICH_ONE to the appropriate value but also set the RRN variable, for the window that is about to be displayed, to what it was before it was made inactive. For example, if I page through the left subfile and end up on page 4, then toggle to the right subfile, I want page 4 to stay on the screen when I toggle back. Without the SFLRRN value from the file information data structure, the subfile will always revert to what it was set to in the SFLBLD routine (in this case, 1). By adding this little technique, the subfile will stick to where it was when it was last active. Again, I invite you to try side-by-side subfiles with and without the SFLRRN value from the INFDS to see the difference.
You Wanted More, You Got More
Side-by-side subfiles are not too difficult to implement. The primary issue is that they cannot be made active at the same time. However, using a little finesse, such as the toggling technique, the USRRSTDSP keyword, and the relative record number value from the file information data structure, you can create elegant side-by-sides that look to the user as if they are all active at the same time. Enjoy. And if you folks out there have other techniques for displaying side-by-side subfiles, share them with me so that I can share them with the rest of the class--and you'll be given full credit, of course.
Contact the Editors
Last Updated: 10/10/02
Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved.