My stock answer is that RDS cut my development time in half over what it took me in c compiled (although I get a lot less magazine reading done waiting for compiles), and the Debugger cut it in half again. I find it useful to the point of frustration when it's *not* available at a client site (back to good old DISPLAY "TEST: ..." statements).
I learned to use the Debugger enough for it to me useful to me in about 90 minutes one Saturday afternoon, and have learned more by using it ever since.
Note that these questions apply to Informix/GX too:
The other problem I saw was multiple repaints of button bars, etc., when using arrows to move among menu/button options. Probably just defensive programming due to early version of 4GX. (They wanted to be SURE that the button bar got changed.) I would hope the newest, refined product would unhighlight the old button and highlight the new button in one repaint.
Borders on pop-up windows have a very nice 3-D look to them. The ring menus become really nifty button bars, which are mouseable, although the old keyboard actions (arrows, hot-keys, etc.) still work.
But the main problem is an aspect ratio distortion. Screens become a lot "taller" so that the GUI widgets, such as apparent 3-D bevelled edges on buttons, can be placed between lines of text. We had to severely reduce the number of lines in some of our screens, because of the aspect ratio problem. In one oversized screen, we had a 30 line array in the text version of the 4GL program. We had to change it to 10 lines in 4GX.
Also, if you use a lot of non-typical, but fully supported, features in 4GL, then you can get into trouble. We had used reverse video to highlight which row of a screen array was being worked on. This looked HORRIBLE in 4GX.
If you use any graphic characters (of the \g-------\g style) in your forms you will discover that they end up looking HORRIBLE in 4GX too.