Strap in, kids; this is going to be a fast ride. The new Screen Designer included in WDSC is just chock full of features, and I want to show you as many as possible within the space we have here.

The Status of Screen Designer

I've avoided writing about the Screen Designer until now because of the controversy surrounding its availability within the WDSC product suite. In case you've missed the drama surrounding the release of WDSC (as reported by yours truly in a previous article), IBM caused quite a furor by including the technology preview for the Screen Designer in only the Advanced Edition of WDSC. Together with the spate of confusion surrounding the terms "unbundling" (EGL) and "deprecating" (CODE Designer), nobody was quite sure what the future of the new GUI-based SDA replacement was going to be.

Well, this kick-started a massive campaign to email IBM and tell them just what the System i community thinks: If they want us to use WDSC, then we need an SDA replacement as part of the base product. Well, I'm happy to say that IBM actually listens, and all of us who complained received a nice letter that said, in part:

"And, while we are currently in the process of evaluating our future packaging strategies, it can be confirmed that when it is ready for 'general availability,' we're committed to delivering the 5250 screen designer as a part of our entry-level System i development tools, like WDSC Standard Edition. Your input has come at a timely juncture, and will be valuable for us as we evaluate our current and future strategy. Please continue to provide feedback to This email address is being protected from spambots. You need JavaScript enabled to view it.."

Well, bully for them! It seems that maybe, just maybe, the System i community can occasionally get someone's ear. It's unfortunate that it requires this much action to get something as seemingly sensible as a screen designer, but at least we know that IBM hasn't completely forgotten the folks who actually write code for the platform. And while there is still no official word on long-term packaging strategies for the WDSC tool suite, after talking to folks in IBM, I'm pretty comfortable that we're actually going to see some reasonable options that will take into account the realities of System i developers. Stay tuned for more on that.

But for today, let's dive right into the good stuff, shall we?

Welcome to the Future!

I don't want to dwell on the past. I want to move ahead. However, I do want to at least introduce you to the predecessor of Screen Designer, which is the CODE Designer component of the CODE/400 product. The primary reason I bring this up is because the CODE Designer is still the only tool you have today to design display files via the workstation. Yes, WDSC's Screen Designer will be the replacement, but it's not soup yet; as I'll show you a little later, it still needs a lot of finishing. So at the risk of being a little bit retro, let me give you just a quick glimpse of the CODE Designer.

Figure 1: Here you see a simple subfile display in the CODE Designer tool. (Click images to enlarge.)

Figure 1 shows the CODE Designer, and as you can see it's got kind of a late '90s feel: lots and lots of button with very colorful icons. While certainly not a bad interface by any means, it is a little busier and a bit more cluttered than the sort of interface we see in more modern applications. For a contrast, take a look at the Screen Designer for the same display file in Figure 2.

Figure 2: This shows the same display file in WDSC's Screen Designer.

I'll get into more specifics momentarily, but I don't think I'm off base to say that the new look is cleaner than the old one. And while this may be in part because I've become very accustomed to the whole Eclipse IDE look and feel, I think the new interface has a number of features (the palette on the right, and the sliders for magnification and grid opacity) that make it feel more up-to-date.

The sharper eyed among us may have noticed something, however, that points out the "preview" nature of this offering. The title and column headings in Figure 2 are green, although they are white in CODE Designer. The fields are actually defined with the keyword DSPATR(HI), which should show them as white rather than green in a color display; the representation by CODE Designer is correct. It's a relatively insignificant issue, but since the whole point of the tool is to design display files correctly, reproducing the proper behavior of attributes is essential. I'm not pointing fingers here; I'm sure the tool will be more completely polished before its general availability. But this sort of glitch reinforces the preview aspect of the tool and explains why it displays the text "Warning: The technical preview is not to be used in a production environment."

On to the Features

The Screen Designer is actually only a part of the whole package. One of the very cool things about WDSC is that various programming tasks can share portions of the tool. For example, the Properties dialog is used to maintain the various values associated with an element of the display file, while the Outline view shows a hierarchical view of the display file (similar to that used by CODE Designer).

There is one downside to this; you may have to move the views around a little bit in order to get a really usable display. If you look at Figure 2, this is the most comfortable arrangement of views that I've found; it requires about 1020x975 pixels, so it will work only on a fairly large display, but it does work quite well.

Screen Association

OK, let's start breaking down some of the really cool stuff that's in the tool. First off is a feature that will be old hat to CODE Designer aficionados but will be a boon to SDA developers: the concept of a "screen." A screen allows you to group multiple record formats together so that you can see how they look displayed at the same time. You can sort of do this in SDA, although it's really quite cumbersome. It's a lot better in CODE Designer, and Screen Designer uses a similar approach: You are able to define arbitrary screens and then add one or more records to the screen. Then, when you edit a screen, all the records can be displayed at the same time.

Figure 3: This is the screen association control.

I hid this control (you do this using the triangular widget in the upper left corner of the control) in the original screen, because it takes up a lot of room and you really don't need to use it often. You primarily use it to relate your records one time or to add or delete records, and then you won't need it again. And as you can see, you start with a default screen named "All records"; this screen is always available and contains all the records in the display file. So in many cases, you won't need to use this control at all.

The Screen Design Panel

The design view of the Screen Designer is quite a powerful panel. Take a look at it in a little bit of detail.

Figure 4: This is the actual WYSIWYG design panel.

There are a number of components to this panel. The most straightforward portion of the panel is right in the middle: the display itself (currently in black) and the palette on the right, which is used to add new fields to the display. Adding fields is done the same as in any other visual builder: Click and drag something from the palette onto the display. I'm not really keen on the UI right now; the drop process simply drops a "default" instance of the object onto the screen. For example, when you drop a text constant onto the display, it drops a literal with the value "Text constant." I think I might prefer an option to have a dialog pop up that lets me key in some information about the field prior to dropping it. That nitpick aside, the basic editor is quite straightforward.

You might also notice that the screen as displayed shows only the top of the screen in color. That's because the top is the "active" record (that is, the one actually being edited). The other records are shown in gray. Note also that all fields have "default" values to show you the size, the same as SDA. Both of these features can be turned on and off via the toolbar on the top of the display.

Figure 5: The toolbar at the top of the display screen controls various features.

In addition to the two features indicated, other capabilities include making the text brighter, displaying help text areas, switching between color and black and white, and turning the grid on and off.

Figure 6: The sliders on the bottom handle the size of the text and the grid opacity.

This brings us to the tools on the bottom of the display. Two sliders are available. The slider on the left controls the size of the text, with two convenience buttons: one to jump to 100% text size, the other to expand to the available width of the workbench. The right slider is a very interesting one: It controls the "opacity" of the grid. The grid starts as invisible, and as you increase the opacity, it becomes first a series of dots and then eventually an actual grid.

Figure 7: The opacity in the grid is variable.

As you can see, the grids can go from subtle to quite conspicuous. If you go much over the 65% shown, the screen is fairly unreadable. I usually leave the grid at 20% and then turn it on and off using the (rightmost) tool button from the top toolbar.

You might also notice at the very bottom of the design panel three tabs marked Design, Source, and Preview. These are the same tabs used in the browser-oriented designers (such as the HTML editor). The Design tab is the WYSIWYG tab; that's the one I've selected for these screen shots. The Source tab switches to the standard text-oriented LPEX source editor for DDS.

Figure 8: This is the standard LPEX editor for DDS.

This view is equivalent to using SEU to edit your display file, although it does have a little more capability, including color coding and rudimentary syntax checking (the editor will ensure that your keyboard shift is a valid value, but it doesn't edit the keywords for a field).

Properties

One thing I'm still struggling with is whether or not I like the use of the Properties dialog to edit the field. The Properties dialog is not technically part of the Screen Designer; it's used by pretty much every part of WDSC to edit the properties of a selected object. From that standpoint, it makes perfect sense to use the Properties dialog to edit a field's attributes. And whoever is architecting the Screen Designer has definitely gone to a lot of trouble to develop the Properties dialogs (I particularly like the way the Attributes dialog is handled; it allows you to condition combinations of attributes, something that even CODE Designer couldn't handle). It's just that I always find myself double-clicking on a field and expecting a dialog to pop up. But once I break myself of that habit, I think I'll probably be quite comfortable with the Properties.

Figure 9: The Attributes tab of the Properties dialog for a field is very powerful.

In Figure 9, you can see the Attributes dialog. I can select one or more attributes to build a keyword—in this case, "DSPATR(HI RI)"—and then assign indicators to that combined set of attributes. The alternative is to apply the same conditions first to DSPATR(RI) and then to DSPATR(HI); in more complex scenarios this becomes very cumbersome.

Figure 10: The Properties view also works at the record level.

Figure 10 shows the Properties view for a subfile control record. Again, the tabbed nature of the Properties tab is philosophically the right way to go for WDSC; I'll get used to it eventually. This is one area where the tool still need some work; quite a few of the keywords are still in "preview" stage. But once this part of the tool is completed, I think it's going to be a big productivity boost especially for newer programmers (but even for older dogs like me who don't know all of the fancy new keywords!).

Outline

As a last taste of the new tool, let me return to the Outline view. Like the Properties view, this view is not technically a part of the Screen Designer; instead, it's a common view shared by many other components of the tool. And as it does in all those other components, in the Screen Designer, the Outline view acts as a superb navigation tool. It's a hierarchical view of the entire display file, which can be expanded down to the individual characteristics of each DDS specifications, as shown in Figure 11.

Figure 11: This is a maximized version of the Outline.

You can drill all the way down to individual keywords, and as you do the appropriate line or object will be highlighted (depending on whether you are in WYSYIWYG or Source editing mode). But when you are using the Screen Designer, the Outline view has one important additional capability: It will activate a record.

Remember how back in Figure 2 the subfile control record was shown in color, while the other records were displayed gray? That's because the subfile control record was the active record. All you need to do to make a different record active is to click on it in the Outline view. That makes it very easy to switch, for example, between the subfile and its subfile control record (as we often have to do when moving a column). And of course whatever you click on in the Outline, its properties show up in the Properties view. This is just another example of the polished nature of the tool already, even though it's not yet ready for production editing.

So Is It Soup Yet?

No, the Screen Designer is not soup yet. There are a couple of little quirks in the display, such as the wrong color for literals with DSPATR(HI), and quite a bit of additional work still needs to be done to support all the keywords. But once this tool is complete, I will be very hard pressed to find reasons why you would still want to use SEU, SDA, or even CODE Designer to maintain your display files.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. and has been extending the IBM midrange since the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books including E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..