Hello RADders and non-RADders,
Because of the messages in this forum about RAD I would like to know why they, who use RAD, do use RAD and why they, who don't use RAD, don't use RAD.
I hope you understand, I know it's very cryptic (magic ) and I am waiting anxiously for your replies.
TIA, Teun.

for small applications with just a couple of windows, there is no big necessity to use RAD. For an application with up to 15 windows maximum, I'd use planes, which are a very elegant way to make small and impressive products. However, if an application has 100 to 500 windows like most of my programs, there are other issues to be solved.
- How can the developer guarantee a uniform user interface throughout the whole application?
As experience tells, whilst making such a big application window by window, the developer gets more and more experienced and each time s/he starts to build a new window, the user interface will change a bit. At first the changes are behind the scenes, later, everyone can see them. No developer in her/his right mind would throw away any working window and replace it with the new interface. Usually, the vast majority of windows deals with data input and only a small number of windows contains the 'nifty' code of the application. But first, the developer has to do these hunreds of boring windows for the basic data input. Customer wants to see functions, not data input. So, there is no time. Whenever you're finished with data input, you're late in the project anyway, so, let's start the real thing. Customer pays for getting invoices, delivery notes, commission reports - not for the ability to input data. So, no one will re-visit those first 100 windows, right?
Here comes RAD. RAD produces a good - and uniform - skeleton of the application. Next thing is, as I have written down in 'What to do after RAD?' to take each of these windows and bush them up in several regards.
- Move / resize / change / add controls.
- Resize the window to a standard-size.
- Fix anchoring.
- Fix Tab-sequence
- Fix data validation
- Make windows idiot-safe
- Take care that no one would see any of these error-windows ever! Show-up of any of the error-windows should be the rare exception!
Note: The general look and feel of the application stays there. I do believe that the Table-Form paradigm presented by RAD is a good one.
- Time. Constantly we are under pressure. The question is: How to make delopment faster without forfeiting on quality?
The answer is RAD + our own cook-book and the principles once laid down for a certain application. The more closely we can keep to a once-set standard, the less buggy the resulting application will be, the faster we can locate an error. I want to see anyone NOT using RAD and being faster than we are. Usually, we can do more than 6 windows / developer / day which accounts to a total of about 120 windows / developer / month. Of course, I'm writing about these standard-RAD-windows only. All other windows are much more time consuming. E.g. a window for input of orders can well take more than one week, sometimes even two. Printing nifty invoices can take the same time, sometimes even more.
- What to do with the time saved by RAD? Simply put more quality into the application. Help, documentation, training material, videos.
Ok, that's it for today
Guenter
We agree on
- user interface (theme, SDI)
- uniform window size (f.i. 1000 x 600)
- RAD and cook-book.