|
Booth, >What it does do is allow an RPG programmer to write true client/server >applications including subfiles with scroll bars, update panels for files, >pushbuttons instead of Function keys, notebooks with various data gathered >in a orderly fashion, graphs, bar charts, colors, point and click >navigation, and windows sized to your choices instead of 80 or 132 >columns. Appearance is far superior to green screen and users generally >prefer the VARPG applications better. With the greatest respect, a graphical "look and feel" are not the same as true client/server. I write client/server apps in plain RPG on the AS400 (no PC) where many interactive jobs communicate via data queue to a single batch server job. Marketing folks might have us believe that client/server means PC/server, but that isn't the case. Why bring that up? Marketing's main reason to sell VaRPG: the claim of being able to "preserve your investment in RPG programmers." If your RPG programmers write S/36 style code on the AS400, they will surely do the same thing on the PC. Having already seen the results of THAT, I can tell you emphatically that the main lesson that needs to be learnt is that Windows programming is the hard part - NOT the RPG/Visual Basic/Delphi part. If your brain is in 5250 block mode, you simply don't think about things like tab order, accelerator keys, resizing the window for different display resolutions and so on. You need to become familiar with the Windows standards and use them. Can VaRPG programmers write Windows standard code? Absolutely! The caution is that they won't do it from the get-go: they'll need training, and a good checklist to make sure they conform to standards. Notice that this whole topic of "information presentation" makes no reference to "n-tier" client/server at all. THAT's a whole other ball of wax; another sticking point when we talk about "preserving" legacy RPG programmers skills in the new multi-platform environment. If I had to pick the main advantage of VaRPG, I'd say it's that the programmer does not have to be concerned with the minutiae of memory management. That's the ticklish part about most of the PC languages. It can also use RPG-traditional I/O to the AS400. The downside is that it has trouble dealing with common Windows standards: Win32 API, DLL's, OCX's and ActiveX. Of course, it's getting better at these with every release. Buck Calabro Billing Concepts Albany, NY +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.