You Can Never Have Too Many RSE Shortcuts

As part of our preparations for the upcoming RPG & DB2 Summit in Minneapolis we've just released the latest edition of our "Favorite Keyboard Shortcuts for RSE" card. All you RSE/RDi users out there, feel free to download and print it. Alternatively there's an email link on the page where you can ask for hard copies of the shortcut card, which are a bit more durable and easier to pin up next to your workstation.

If you already have an earlier version of the card, you won't notice a dramatic difference, but we have made several improvements. For example, this one has a new section for the debugger shortcut keys, which were missing from the earlier versions of the card. Plus a few editor shortcuts have been added  for commenting or uncommenting statements in RPG and switching between sides of a single-member split view, among others.

It was a bit of challenge finding space for the new stuff we wanted to add as the list has grown quite a bit from our original version (this is about the 4th edition). We toyed with the idea of making the fonts smaller, but decided that if we did that, our old eyes probably wouldn't be able to read them any more. We're sure the younger RSE users out there wouldn't have any trouble, but we would like to be able to use the card too! Instead, we gained some space by condensing a few of the items in the "Windows Shortcuts" section, taking multiple lines down to a single line. We figure that many RPGers are now more comfortable with Windows applications than when we first created this card and so don't need quite as much help with those.

There's also a new "tip" on the back--a very brief tutorial on getting started with Service Entry Point (aka SEP) debugging for those who may still be struggling with making the integrated debugger work.

Of course, no sooner had the email about the new card gone out to the folks on our System i Developer mailing list than an email came in suggesting that we missed a good shortcut--Ctrl-Shift-D for filtering a source member by change date! Thanks for that tip, Irene. We agree it is a good candidate to add to the list. If only we had thought to ask folks for suggestions _before_ we printed 1,000 copies of the card <sigh>.

Then again, it's never too early to start planning for the next version! So everyone else--please send in your own ideas of shortcuts that we missed. It will probably be a while before we reprint the cards again (unless it becomes so popular that the 1,000 copies we have get used up quickly!)

In the meantime, if we get lots of good suggestions, we'll start an addendum to the card online in the form of an extra item on our "RSE Tips" page.

So please tell us about your own favorite shortcut keys in the comments section. We're sure there are some great ones that we simply haven't bumped into yet and you can never have too many shortcuts!

RSE Trials (and Tribulations?)

In our latest EXTRA article we wrote about our favorite tool for developing RPG/COBOL/CL/DDS code--RSE, which is currently packaged in RDi, previously in RDP and WDSC.

In that article, we pointed out that there is a 60-day free trial for RDi. We've heard of some issues users have had related to downloading the trial and then turning the trial into a licensed program. Of course, the second part assumes, as we anticipate, that you will be sold on the value of the tool by the end of the trial period. So we thought we'd point you to a few hints and tips that we've found on both of those processes.

Downloading the trial code. The download page is easy enough to find here. There are a few things to keep in mind.

 

• You will need an IBM ID to do the download. It's free but a step you'll need to take before you can complete the download. You won't need your IBM customer number or anything so it's relatively painless to get an ID if you don't already have one.
• Later you'll see that there are two different ways to download--via Download Director or http. A link on the page describes some of the differences. Download Director seems to have better recovery options if you encounter problems during the download but your mileage may vary on that.
• Next you'll see that there are four different zip files (disk images) to be downloaded, each is more than 1500 MB. We've heard widely varying experiences of how long it takes to do the downloads. Suffice it to say that many (but not all) have found the download to be measured in hours rather than minutes. A couple folks' downloads have taken days! So be prepared for a wait. If you're just loading the base RPG/COBOL tools then you can install with only the first two disk images. However, when you go to apply Fix Packs, it may ask for the other two images because there may be fixes for those options. So although you will probably need all four disk images eventually, you can do your initial install once you have the first two. If you need help with what to do after downloading the disk images, take a look here. Choose Installing > Installing Rational Developer for i > Installing from an electronic image: task overview.
• It's also possible to install it via the internet without requiring a download of the disk images. This is the way we installed trials of earlier releases but this time the trial download page doesn't mention that. It does require a bit of manual intervention so if you want to try that option, take a look at the helpful guide, which was helpfully provided by Eric Simpson on the IBM developerWorks site. Jump down to the update on June 19, 2013, on that page for the details. You may find this faster if you're just looking to install RDi on one workstation rather than several.
• Next, let's say you have the trial installed and, perhaps with the help of our "RSE Quick Start Guide," you get started using it and get hooked. So you purchase a license to RDi. The license can be purchased in two says--via Passport Advantage (aka the software channel) or through the same way you order your hardware and operating system, probably from an IBM business partner (aka the hardware channel). We won't attempt to explain why you might buy it one way vs. the other because we're not really clear on that question ourselves. (If any of our readers can help answer that from your own experience, feel free to comment below.)
• Once you purchase your license, you will need to get a file that contains something called an Activation Kit. Once you get your Activation Kit, it's pretty straightforward how to use it. If you need guidance, the same link we referenced for help with the installation process has a section on "Activating your product." Getting the file containing the Activation Kit can sometimes be more challenging. Once again, a helpful IBMer, Edmund Reinhardt, this time, provided some documentation on that subject on developerWorks.

After you have installed and successfully activated RDi, enjoy the great features you find there. And if there are features you think it really needs that you don't find there, consider putting in an RFE (Request for Enhancement), as we blogged about some time ago.

Rational Developer for Power Systems 8.5 & Beyond

You don't have to have been following this blog for long to know that we are both big fans of RSE, which is currently packaged in Rational Developer for Power Systems (RDP). Many of you are probably RSE users as well and you may have noticed that Rational came out with a new version, RDP 8.5, back in June. If so, you may have wondered why you haven't seen us blog about it.

Well, we installed 8.5 and while there was at least one really major new feature we liked, we also encountered a few idiosyncrasies that gave us some problems. In particular if a connection dropped while we had source files open, it took forever to get the workbench back in action as you had to respond to a seemingly endless series of connection-related dialogs. None of them offering the option to work off-line, etc. Admittedly we are perhaps unusual in that we often travel to a client site, connect to their system, and then go back to our hotel with the sources still open, knowing that we will be back on site next day. Once we open up the laptop again it can take 10 to 15 minutes to regain control. There were other issues, but to be honest, neither of us can remember exactly what those were. We're also not sure whether they were new features that we just needed to learn how to utilize properly or whether they were bugs. We also saw several reports on the WDSC-L list on Midrange.com and other places of other people who were having trouble with 8.5.

Bottom line, we are both so addicted to using RDP for our development that we decided to postpone digging into it for a while. Fortunately, we had also kept our old installation of RDP 8.0.3 so it was an option for us to keep on working with that version.

The good news is that a fix pack for RDP 8.5 has recently become available. So maybe it's time that we give 8.5.1 a try and see if it works better for us than our earlier attempts at 8.5.

Another reason for postponing the use of the new release is that we didn't have a really burning requirement for the only significant new feature that we heard about in the community--a dynamically updated Outline View. It's a nice feature, to be sure, but since we don't work as much with very large programs, occasionally refreshing our Outline Views isn't exactly a huge burden.

And we also had real difficulty finding a good list of any other enhancements in 8.5 that would cause us to want to dive in right away. We have now found such a list on developerWorks and thought we'd share with you, just in case some of you are also postponing the upgrade. So here it is--courtesy of Dave Dykstal--a nicely detailed list of new features, complete with link to a video of the RPG Outline View enhancements by Edmund Reinhardt.

But wait, that's not all! (sounds a bit like a late night infomercial, doesn't it?). The 8.5.1 fix pack includes several new features, not just bug fixes. You can read all about the 8.5.1 fixes and enhancements here. Spoiler alert: any IBM i COBOL programmers out there may want to pay particular attention to the Outline View in 8.5.1, according to this list. They have waited a long time for a usable Outline View, and it looks like their patience has been rewarded.

Maybe in a future blog post, we'll report on our findings of all the cool new things we've experienced in 8.5.1. As soon as we're both able to get the fix pack installed, that is. Jon's update to 8.5.1 worked flawlessly, but Susan seems to have hit a (hopefully temporary) snag.

In the meantime, any of you who have used 8.5 or 8.5.1, please feel free to share your experiences in the comments.

The Why and How of Moving From SEU to RSE

We published the first couple of installments of our newly updated "RSE Quick Start Guide" in the IBM i EXTRA newsletter over the last month or so. There we promised to update you when the rest of the guide was available for download. 

It is now available from the System i Developer downloads page. So if you have been looking to get started with RSE yourself, take a look. And for you RSE veterans out there who have been looking for a way to chip away at the excuses from your SEU-laden colleagues, maybe the guide can help.

We wrote the Guide to be very task-oriented, but there is a very small piece near the beginning that discusses why one should consider moving from SEU to RSE. The hardest part about writing that section was deciding which things to highlight from the dozens of reasons that make RSE the obvious choice for us. We were helped by the fact that Susan recently developed a conference session called "My Favorite Things about RSE." She had a lot of difficulty coming up with that list, but at least it was a starting point for paring down the list to 7 favorites for the guide.

Maybe some of you RSE users out there can help us out with future efforts in this area. What are those "killer features" of RSE that make you wonder how you ever managed to write code using only SEU/PDM?

To get the discussion started, here are the 7 features we listed in the Quick Start Guide.

1.  More lines of code on the screen (typically 2 to 3 times what SEU shows)
2.  Filtered source code - by change date, to remove comments, show control flow, etc.
3.  Unlimited levels of Undo & Redo - even after a save and compile
4.  Tab keys work without prompting (and can be customized)
5.  Multiple source members open for edit at once
6.  An Outline view cross referencing all fields (internal and external), subroutines, etc. 
7.  Compile error feedback without closing the source and without spooled file listings

Please let us know via the comments if these features would make your own list of top reasons to code using RSE and which killer features we managed to leave off the list.

 

P.S. If any of you emailed us in the last week or so and didn't get a response, please try again. Our email server recently made some changes to our account and apparently some number of emails just disappeared somehow.

Lawson Software Users Flock to RSE (or at Least They Should!)

It's conference season again! For us, that means travel season--even more so than our normal travel schedule. Most of the conferences we attend are hosted by local user groups. We were in Wisconsin in March for one of our favorite events--the annual WMCPA conference, followed by our own RPG & DB2 Summit, which involved quite a lot of interaction with the MMSA user group in Dallas. One interesting aspect of both conferences was the increased number of younger developers in attendance. WMCPA always has a few because their president, Jim Buck, usually brings a group of his students along to assist and participate. But we were very pleasantly surprised to see the number of younger folks at Summit--we're used to Aaron Bartell being the youngster!

The following week (now) we're at the NEUGC event--a unique event where multiple local user groups in the area pool their resources to put on a successful and fun conference each year. Once again there seem to be a few younger folks around, but the really good news is that overall attendance is up. We should all applaud that. Next week, we head to Fort Wayne, Ind., for an all-day session focusing on RSE hosted by the local user group there. Then the day after returning from Fort Wayne, we head to Sweden for a developer conference there. The following week our own local user group, TUG, holds its annual TUG TEC event, which is followed by the grandaddy of user group conferences, COMMON in Anaheim. We'll be speaking at COMMON this year for the first time in a while; it will be nice to see some old friends again.

So what does all this have to do with Lawson? Today at one of Susan's RSE sessions at NEUGC, she had the pleasure of making one person really happy over the idea of using RSE to edit source code. In fact she was positively ecstatic. Many SEU users are happy when seeing the productivity features of RSE than leave SEU in the dust. But ecstatic? That is the reaction you get when you're a programmer who can't even use SEU to edit her RPG source code!

What would programmers be using instead? How about EDTF (Edit File)? Never heard of it? It's the green-screen editor for IFS stream files. You can get to it from WRKLNK. Imagine: no PDM or even SEU. Just WRKLNK and EDTF to edit your source code. Next to EDTF, even PDM and SEU look like the greatest programmer productivity tools ever invented. If you've not had the pleasure of using EDTF, perhaps you can remember eons ago using a truly rudimentary editor called EDLIN. EDTF is a tad more advanced that EDLIN but not a lot.

Why has this person been editing RPG source with as primitive a tool as that? Because her source code is stored in the IFS and it was the only editor that she knew of that could edit IFS stream files.

She's not alone. More and more shops are finding themselves in the position of having to edit source code in the IFS because Lawson's recent releases started storing and shipping all of their source in IFS files rather than source members in regular source physical files. Who knows why they would decide to make that rather strange decision? Perhaps someone out there among our readers can enlighten us. Perhaps even stranger is the fact that Lawson doesn't seem to have told their users that RSE is the way to go for editing the code.

Regardless of the reason, the effect has been a dramatic drop in programmer productivity among those RPGers who must make changes to the Lawson code because EDTF is the only obvious way to do it--at least if you're limiting yourself to green-screen tools.

Now the person in Susan's NEUGC session today has learned that RSE (packaged in RDP/RDi/WDSC) has no problem whatsoever working with source stored in IFS stream files, and hence her unbounded joy. RSE can seamlessly handle IFS files for editing, compiling, etc., in exactly the same way it works with source members for the rest of the IBM i community.

This individual wasn't the first Lawson programmer who couldn't wait to get her hands on RSE. One of our recent private classes was to an entire group of Lawson programmers who were equally ecstatic over the prospect of leaving EDTF in the dust.

Now, if we could only get the rest of the SEU users still out there to a have similar revelatory moments about how much more productive they could be ...

Calling All RSE/RDP Users--Vote Now!

Back in December we blogged about the RSE wish list. But lately, we've discovered that it seems not many of you followed up on our suggestion, so we're taking another shot at it.

IBM developerWorks has a place for submitting and voting for your favorite requests for enhancement (RFEs) for RSE (and/or other Rational products). Many of the requests we have heard most often from RSE users are already on the list. If some of your favorites are already there, add your votes to help direct IBM's development efforts to the features that the most users want/need.

For example, we took a look at the top 20 voted RFEs for Rational Developer for Power Systems. Some of our favorites are in the top 20, such as an SQL prompter, the ability to re-indent /Free-form RPG code and--our personal pick--support of RDP running natively on Mac.

So there are some great RFEs out there. But the sad thing is the small number of votes that have been cast for the enhancements. Given how many RSE users we hear from who want some of these functions, there should be (at least) hundreds of votes out there for several of these RFEs. But when looking at the top 20 RFEs by number of votes, as of yesterday, we found fewer than 50 votes for even the most popular ones.

Susan taught two RSE sessions yesterday at the RPG & DB2 Summit in Fort Worth, Texas. Each had enough people present to double the votes for nearly all of the requests if every student present voted for them.

Just as Susan challenged all of her session attendees to go look at the submissions and vote for their favorites, we're now challenging all of you out there. You can put in your own suggestions as well. But make sure you check to see if something close to your own requirement is already out there so that you can simply add your own vote.

It's easy to add your opinion. Go to the website and create an IBM ID if you don't have one already. Under "Browse RFEs," look at the top 20 voted RFEs. Then choose Brand: Rational, Product family: Design & Development, Product: Developer for Power Systems. There are many other ways to browse and search for RFEs if you don't see your favorites in the top 20.

Don't just sit there, VOTE. Your favorite tool needs you.

RSE Wish List--Now With Clout!

Almost a year ago, we wrote about our own RSE feature wish list and many of you responded via the blog.

We recently attended a meeting of TUG, our own local user group, which was held at the IBM Rational Toronto lab. Not surprisingly, the topic was RDP. Actually, in a way it was a bit surprising that the focus was on "just" RDP rather than the more expensive packages/add-ons such as RTC. Kudos to the lab folks for resisting the urge to up-sell!

Out of all of the information covered in that session, the one item that piqued our interest most was the mention of a Web page where ordinary developers can enter and vote on requests for enhancements (RFEs). So we couldn't resist taking a look at the RFEs currently out there for RDP to see how our favorites were faring in the voting and what other requests had been made.

We'll hit a few highlights here, but we strongly encourage those of you who use RSE to visit the site and cast votes for your own favorites and/or even put your personal favorite new/changed feature request in for consideration. You'll need to create an IBM ID to do this if you don't have one already, but it doesn't require a customer number or serial number or anything like that, so you can set one up very easily.

We looked at the list of the top 20 vote getters for RDP. We're a tad disappointed at how few of our personal favorites were in the list. What we haven't yet done is figure out whether the rest of our favorites have even been requested. If not, we'll be entering some new requests of our own very soon!

Looking at the top 20 by votes, we're gratified to see that one of our favorites--the ability to indent/reformat existing /Free RPG code--is second in the list as of this writing, with 29 votes. We'd especially encourage everyone to vote for this one, even though it's near the top of the list already, don't assume it will stay there. This is one of the most requested features we hear from RSE users and lots of votes could help propel it to a status where IBM will more seriously consider adding it!

On the other hand, we're a bit concerned about the request at the very top of the list--constantly update the Outline View with changes made in the editor. We understand the value of such an enhancement. However, as a few people have pointed out in the comments on this one, there are concerns of the performance impact of such an enhancement. Even if the outline view were to only be updated from local editor changes, which is how the request is currently stated, it could still impact the performance of editing, perhaps dramatically especially for very large source members, given the way the Outline is currently populated. At the very least, if IBM decides to do this one we hope IBM follows the advice as stated in the comments, making it a feature than can be turned on and off, preferably in a very easy way (hint: not searching through hundreds of preferences pages to find the right one!).

We believe this Outline View request is a case of "be careful what you ask for" and encourage any of our readers who may decide to cast a vote for this feature to also add their voices in the comments section that this should be optional and also should only be done if it can be accomplished without noticeable editing performance degradation in medium to large source members.

We are delighted to see that another of our top wish list items is also in the top 10, although we would love to see it even higher than its current No. 7 (as of this writing.) That's the request for RDP to run natively on Mac. Yes! We love our Macs and we love our RDP. If we could run RDP as a native Mac application (without using the Windows virtual machine we currently use), we would be to very happy-- no, ecstatic--campers! We fear this may become a sort of chicken and egg situation. IBM i folks don't use Macs because tools such as RDP don't work natively on Macs. Consequently, they don't request Mac support because it doesn't impact them immediately. Please consider voting for this one, even if you don't use a Mac today. Wouldn't you like the opportunity consider using a more stable and reliable workstation platform--much like the more stable and reliable server platform we all know and love?

A request for SQL prompting is in the top 20--one of the requests that we forgot to put into our original wish list, but were grateful to our readers for pointing out the omission. We're a little surprised it's as far down the list as it is at the moment. If you use embedded SQL and RSE and think this would be helpful, by all means, cast your vote!

The list contains many more very useful features so we could go on and on commenting on other items among (and not among) the top 20 vote getters. But we'll save more comments for another day, another post.

Now, don't just sit there--go out and vote!

What We Are Thankful For

We live in Canada and consequently our Thanksgiving was in a few weeks ago. However, as in most years, we were working in the U.S. that day, so we tend to celebrate in November. So as we near the Thanksgiving celebration, our thoughts turn to things we are particularly thankful for.

We have many personal things we are thankful for. These include our health (including our wonderful Canadian healthcare system), our families (including four exceptional grandchildren), our home (which we sometimes wish we could spend more time in than we do), and many more things that we could go on for hours listing. We are truly blessed.

But in this post, we thought we'd concentrate on those things related to our work with IBM i that we're particularly thankful for.

First of all, we're grateful to still have work and a good income, despite the state of the economy. We know many who are not so fortunate. Many IBM i shops seem to have decided that an uncertain economy is a good time to exploit their investment in existing applications by moving them forward, enhancing their applications' value and the developers' productivity. That just happens to be our specialty, so it has worked out well for us.

We're grateful that the developers of our favorite programming language--RPG--have never even considered resting on their laurels. They could have simply cashed in on the maintenance revenue stream for applications running the businesses of thousands of companies worldwide. Instead, they have continually made the language more modern (/Free, data structure enhancements), more powerful (native XML processing, enhanced file handling), and especially recently, more easily expandable (via RPG Open Access or OA--more on OA in a moment)

We thank our lucky stars every day for RSE (the toolset currently packaged in RDP, earlier in RDi and WDSC). It's almost painful to recall our days of SEU development, with DSPFFD to get externally described field names and spooled compiler listings to find compile errors (shudder!).

And we're delighted that Rochester has given us a new friend to play with by embracing PHP on our favorite platform. If nothing else, PHP allows us to breathe a sigh of relief that we don't have to keep beating our heads against the Java brick wall. PHP gives us another option for a modern, browser-oriented language environment that lets us use OO to the extent we choose and offers an amazing wealth of open-source tools and applications. All with relatively simple integration to RPG applications and IBM i function. And best of all, it makes sense to those of us with RPG brains.

We said we'd come back to RPG OA. That's simply so that we can remind you that it was about a year ago that we made a plea for rational thought (pun intended) to prevail related to the Ts and Cs for OA. We have seen some progress. A trial version is available, at last. But we're still waiting for the true solution that we still hope will come--OA support to be included free-of-charge with either the OS or the RPG compiler. We have read rumors to the effect that we may not have much longer to wait for this. It would make a really nice present to find wrapped up under our Christmas tree!

Most of all, we're simply thankful to have had the opportunity to make a career working on the best platform on the planet for business applications.

Last, but by no means least, we're very thankful to all the readers of this blog. When the IBM Systems Magazine folks asked us to begin writing this some years ago, our first reaction was "but who would want to read what we have to say every week?"  Well, apparently, quite a few of you would. We're gratified and humbled at the number of you reading our weekly posts. Thank you all.

And a very happy Thanksgiving to all--whether in the USA or elsewhere--we all have a lot to be thankful for.

The RSE Wishing Well

Thanks to all of you who added your thoughts on the subject of our last EXTRA piece, An RSE Wish List. It sounds like we're not the only RSE fans with a wish list.

We were particularly gratified to see the comment from our friend George Voutsinas from the RD Power Development team, indicating that at least some of our (and your) wishes have made it into the list of requirements. Like all of our end users, we look forward to seeing all the requested changes implemented immediately <grin>!

BTW, for those who have yet to visit the RD Power Hub site George mentions, take a look. It's an important site and one that should be high on the “visit regularly” list of all RD Power users.

We wish we could report that visits to the RD Power Hub, as well as its cousin, the RPG Café, are happy experiences. We want to love these sites, but we’re frustrated nearly every time we visit. The interface seems (to us, at least) non-intuitive and lousy performance doesn’t help. Are we alone in thinking IBM is in desperate need of some good website designers? Or perhaps the ones they have need to be “liberated” from whatever legal or bureaucratic constraints they currently live under?  Still, the developers who hang out on the forums and participate in the discussions there do offer a lot of helpful advice. Read on for some evidence of that later on in this post.

Thanks also to Thierry (who must have been collecting an RSE wish list for some time) for your thoughtful additions to the list. While we know it's not nearly as nice as the feature you asked for, we recently discovered one technique to find the definition of a field in the editor. If you select the field and then use Ctrl+Space, you can see the definition without needing to go over to the Outline view.

Scott's request (that was seconded by Aaron and Steve)  was for much better SQL support--how could we have forgotten to include that one in our own list? Yes, we definitely support enhancements to embedded SQL support in the editor, whether or not implemented exactly as suggested. For sure, embedded SQL is a definite weak spot in an otherwise great RPG editing tool.

Dibs also offered good ideas. We like the idea of being able to export a source member or list of them, perhaps for email purposes. We have taken advantage of the ability to copy and paste a source member to a local file for the purpose of e-mailing the code, but having something a bit more architected into RSE for that would be nice. And the ability export (or copy/paste) lists of items from the "Show in table..." view would also be great.

As to the support for a version of RD Power on Mac: we're convinced there's a growing desire for this among IBM i developers. Jon recently examined an alternative Eclipse-based RPG editing tool--Michael Schmidt's RPGNextGen. While its native Mac support is a big plus, it's missing so many RSE features that we've become addicted to that it doesn't seem like a good contender as an RSE alternative at the moment. On the other hand, it's free, so those of you still stuck hopelessly in SEU-land may want to consider it.

We've had a few reports recently of some very strange behavior when using the “C” and “A” line command method of copying source member lines. Thanks very much to Tammy (and others who participated in the conversation) for taking this issue up on--of all places--the RD Power Hub's discussion forum. As a result, we have two important pieces of information. First, the problem as reported has a work around. If you turn off "Column sensitive editing" in your preferences, it seems to clear it up. Second, the Rational development team has noted the problem and plans to have a fix in the next fix pack, whenever that may be. Since the availability of fix packs seems to be the most common recent subject of blog posts on the RD Power Hub site, check out the blog from time to time to find out when that may become available.

Thanks for your participation in the discussion. Keep the thoughts coming!

The DDS Designer Showdown

For our EXTRA article this week, we wrote about the new DDS Designer--the one integrated with RSE in its latest incarnation as part of RDP or RD Power or ….  

In that piece, we couldn't help drawing parallels between the new DDS Designer and the CODE Designer. We're extending that discussion here and inviting your participation.

Neither of us are big fans of SDA and we pretty much considered RLU hopeless. CODE Designer, while far from perfect, has been our DDS designer of choice for many years. When the integrated Screen Designer came out as a Technology Preview, we spent some time with it. But since it wasn't recommended for production work, we didn't teach it in any detail in our private RSE classes 

Now that the new designer is officially supported, we're beginning to teach it, and in doing so, running into the inevitable comparisons with what came before--for us and for many of our students who are/were CODE Designer users as well. Which do we like better? That's not an easy answer. There are some really nice new features in the new one, but at the same time, we miss some of CODE's features.

First of all, the new designer is space hungry; it seems to work best with a large monitor. Since we spend so much time working on a laptop screen, this gets frustrating. The new designer makes extensive use of an expanded Properties view, much like the properties notebook we used in CODE. We could make the properties view a fast view or detach it, which would feel more like opening the CODE properties dialog. The difference is CODE had many of the most-used properties integrated at the top of the design screen (i.e., name, data type, length, row/column, color, display attributes, etc.) so we didn't need to use the properties dialog as often. With the new designer, the properties view is the most obvious place to change these things, so after dropping a named field onto the design screen, we want to use properties to change the field's name, data type, etc. and we need to use multiple tabs on the properties view to get to things like display attributes and color. This isn’t a big deal if you have a large monitor available, but it’s an irritant compared to the ease of adding new fields with CODE.

On the other hand, one option for changing those things that’s quite feasible with the new designer is to click on the source tab and directly edit the DDS source. The changes are immediately reflected on the properties view and the outline view and, best of all, you can quickly flip back over to the design view to do additional work. The ease and speed with which we can flip back and forth between graphical design mode and raw DDS-edit mode is miles ahead of CODE. Yes, you could do it in CODE, but it was slow and painful, so we rarely did it.

There are a few irritants in the new designer, such as the inability to key static text on the screen directly. You must first select an item from the palette and then change its contents. This isn't horrible, but seems unnecessarily cumbersome compared to what we did with CODE. Similarly, to lasso multiple items on the screen, you must first select the marquee tool from the palette. Why? This is particularly frustrating when you lassoed them to move them and you must manually switch back to the other tool from the palette to move the lassoed items. Not show-stoppers, by any means, but irritating to those of us who used CODE.

On the other hand (again), with the new designer (in its latest incarnation, not in some of the earlier technology preview versions) you may use the graphical designer to design a single record format. You’re not forced to put it into a group (CODE term) or a screen (new designer term). The concept of a group/screen is great for those occasions when you need it, but much of the time, working with record formats is all that’s necessary. You do seem to be required to create a screen if you want to use the preview faculty, for some reason, which is also where the indicator sets and sample values for screen and report fields can be used.

The use of the field table to drop database reference fields onto a screen is great. Yes, we could do a similar function in CODE, but this one seems a little simpler and makes good use of an existing RSE feature that shows off the integration of the tool set, as does the use of the outline view for navigation, which replaces the "DDS tree view" of the CODE designer.

Other niceties in the new designer include the sliders to adjust the screen-image size and the visibility of the grid lines on the design screen. One of our other favorite features we ran across by chance is the capability to peek at the source code for the selected item on a screen (including an entire record format) by hovering over the name of the item just above the design screen image. The source for the item pops up in a box over the design screen--a very cool feature.

Of course, "undo" is more useful than making and reverting to checkpoints in CODE.
But we find we do miss the capability to distribute a group of fields evenly across a screen.

We could go on with the comparisons, but perhaps we've said enough for one blog post. All in all, we like the new designer, even more than the CODE designer. The very notion that it’s truly integrated with RSE makes a difference and some of the new features are nice. We're hopeful the new one may, over time, re-learn a few of the tricks its ancestor had as time goes on.

We're anticipating comments along the lines of "why are we even devoting time and energy to a DDS screen designer when the world has moved on to browsers and other non-green-screen user interfaces?"  Our reaction to that is some have moved away from green screens at a slower pace than others and why shouldn't maintenance of those applications be as productive as it can be? Maybe they can use the time saved to work on modernization efforts!

If you’ve experienced both designers, help us continue the discussion via the comment section. If you haven't used the new designer yet, take a look at EXTRA when it comes out this week.