Last Friday I was presenting at the Wisconsin user group (WMCPA) on various RDi related topics. It was their all day fall conference and it went really well IMHO. Here are a few random thoughts from the day.
There is a mental shift moving from the green screen "single task" based tools to the "multi-task" based RSE environment. I'm not just talking about the learning curve of learning a new tool, it's more about the mental shift of really understanding how the new tool works.
That's a bit abstract, so let me try to make it more concrete with an example. Recently I've gotten the following question from 3 different people: "Can I run a CL command while editing in the RSE?" The assumption seems to be that, while the editor is open, you can't do anything else. This is what I'm referring to as the single task mode (yes, I know SEU allows you to run a CL command, but that takes over the editor while you are doing it). Another example: while you are debugging on the green screen you can't also be editing code unless you open multiple emulator sessions.
In the RSE you can do most things at the same time. You can run CL commands and work with your objects and members while editing, you can edit multiple members at the same time, you can be debugging one or more programs in the debug perspective and then switch to the RSE to do some other things, then switch back and continue debugging. You can use the RSE in a single-task mode, but over time you make the mental shift and really start leveraging this power. This is not something that can be taught, it just comes with time and experience.
Second observation: always find out the true problem before giving an answer. There are many ways to do things in the RSE, you just need to find the way that best solves your problem. I've written about this before, specifically about using spool files to find compile errors and cross reference information vs. using the Error List and Outline view.
I came across another case of this while running the open lab. A woman in the class was trying to get F1 help for an RPG built in function, but when you press F1 on a BIF it takes you to the help for the opcode (a possible defect?) So I embarked on showing her how she could find the help page that lists the BIFs and bookmark it so she could always jump back to it quickly. She seem okay with this, but not overly thrilled.
A few minutes later she mentioned that she only needed the help because she can never remember what parameters some of the BIFs require and the order they are expected. Ahhhh! What she really needed was the content assist for the BIF which shows you the parameters and a small help blurb. When you select the BIF from the content assist list it even puts up a hover box showing the parameters until you have them all entered in. This got the excited response I was hoping for.
My last observation is more of a comment. Jim Buck, who is the president of the user group, is also a teacher at Gateway Technical College which has an IT - Programmer/Analyst programthat teaches System i and RPG programming. Very cool!
