- 4GL Enhancements
4GL Extensions (Only Available in FWD)¶
The following facilities are 4GL syntax extensions that work in FWD but will not work in OpenEdge.
- Some of these enhancements can be achieved in OpenEdge by using 3rd party native code, OCX, COM, .NET, Windows-specific program or WIN32 API to achieve the same result. Replacing them with the FWD version results in much cleaner, more reliable code.
- Other enhancements are simply not possible in OpenEdge.
Browse Widget Enhancements
Cross-Session PUBLISH and SUBSCRIBE
Direct Java Access
Embedded Mode Web Client
Font Control in 4GL Widgets
FWD-VERSION Preprocessor Define
Generate an Excel Spreadsheet
HYPERLINK Browse Cell Option
HTML-BROWSER Widget and OCX Replacement
ImageList Widget and OCX Replacement
Menu Mnemonic and Preprocessed Label Attributes
Mouse Position Location
Native API Emulation
Progress Indicator Widget and OCX Replacement
RESIZE Attribute in Dialog Box
RGB Color Support
Screen Refresh Control
SYSTEM-DIALOG GET-FILE AT-WEB-BROWSER UPLOAD
TAB-SET Widget and OCX Replacement
Timer Service (PSTimer OCX Replacement)
TREEVIEW Widget and OCX Replacement
Working Directory Control
What if you could help make the 4GL a better language? Have you ever wanted to actively participate in imagining, designing, implementing and testing new language syntax and features? With FWD, this is possible.
Progress has a reputation for being "conservative" with adding support for new features. GUI support was first introduced in 1993 (v7) and it wasn't until 1994 that the updated v7 was stable enough for real GUI development. This was 5 to 7 years later than the rest of the industry moved to GUI. By 1990, it was clear that moving to GUI was going to be the next wave of UI development. Considering that GUI was feasible for the first time in 1993/1994, one might conclude that Progress was not keeping up with the legitimate needs of business applications.
OO came for the first time in 2006, a full 16 years after it started to become popular. 64-bit data types were the big upgrade in 2007, C and C++ programs in the early 90's could use 64-bit data, Java had 64-bit data at its inception in 1996. Functional programming, inversion of control and other powerful techniques are still not available.
The list of missing features is very long, but perhaps the biggest miss in the last 10 years is the lack of any way to reuse 4GL GUI screens in the web. Progress tried the CGI-like WebSpeed approach, which is not suitable for modern web applications. Progress' advice now is to throw away all of your GUI screens and rewrite a new front end with web-native technologies. A decade ago (or more), the world changed. Windows GUI applications become a negative rather than something customers wanted. No one wants a Windows application now, everyone wants a web application. Progress has missed the modern web by 10 years and has given no sign that there will ever be a way to write a modern web UI using 4GL UI constructs.
Progress does not make it a priority to keep OpenEdge up to date with the most common business application requirements. Over decades, this approach has led to a result best summarized by Yogesh Gupta, CEO of Progress Software Corporation (January 17, 2017 4Q Earnings Conference Call):
While our OpenEdge partners continue to modernize and sell their applications to new customers, we are not attracting additional partners to develop new applications on this platform, nor are we attracting new direct end-user customers. Based on this profile, our expectation over time is for flattish revenue from OpenEdge, which we believe is a very good result for such a mature established business.
Many 4GL developers love the language but wish for additional features. More than a few have wanted to extend or customize the 4GL features for their own purposes. The solution to this is often to write some kind of framework code in the 4GL, but since the language does not provide a way to add features that are equivalent to the 4GL syntax, all these frameworks tend to suffer from 2nd class citizen status. Typically they end up more complicated than necessary and often rely upon preprocessing for their implementation. In other environments, one can choose from a wide range of 3rd party frameworks and libraries. With the 4GL, the choices are limited and it takes more work to achieve a lesser result as a consequence. Developers can be forgiven if they find themselves frustrated by problems and limitations which Progress could have long since solved.
The FWD project takes a different approach. It starts with the premise that the only way to move ahead over the long term is to make sure that the toughest problems are solved. Using an open source development model, everyone can contribute and solve the problems most important to themselves. Many of these solutions require new syntax or an optional execution mode where a not fully compatible version of a feature could be implemented. There is every reason to add the best ideas into the core FWD technology, making it more useful and powerful for everyone.
Some of these enhancements would be delivered as new 4GL syntax (which is not supported in OpenEdge). For 4GL code that must run in both FWD and OpenEdge, this new syntax would have to be conditionally preprocessed or implemented via different include files. Such additions don't exist in OpenEdge today, so there are no compatibility concerns except that they need to integrate without breaking existing 4GL code. The only key here is to design the new syntax to minimize possible future conflicts with 4GL changes that come from OpenEdge.
Other enhancements might change the behavior of existing 4GL functionality (e.g. an enhanced version of a browse widget). To enable such an improvement, some configuration would be needed (at conversion or runtime). These changes would necessarily change compatibility with the current OpenEdge implementation but would only be used when requested.
The key design criterion is that nothing should be done that would break existing applications. But it is safe if a user explicitly codes new 4GL syntax or configures a runtime mode that enables an enhanced replacement. Contributions will be accepted within these constraints. Golden Code is also available to provide development services.
FWD already provides a good example of this approach. Entire ADM/ADM2 applications including all their 4GL GUI screens can be used in the FWD web client without a rewrite. By enabling 4GL constructs to create and drive a web experience, FWD solves the toughest of problems and delivers the environment that business applications require today. Without FWD, developers with an 4GL GUI application are facing a multi-year investment in replacing the entire UI with a new front end. The Progress approach is expensive and time consuming, wasting resources and years of effort.
Ideas for Future Enhancements¶
This section is still being filled out. Join the project and let us know what features and enhancements you need the most!
- instantiate Java objects and call Java methods directly in 4GL code, leverage the same basic syntax integration as for
USINGstatements to import Java packages, direct references to Java classes/methods/fields in expressions), see #3867
- multi-threading for 4GL code, make sure to include synchronization and data sharing primitives (each thread probably needs to run as a separate session, only 1 thread can drive the UI), see #3254
- query a count of the number of records in a given table that match a given WHERE clause (or no WHERE clause)
- new UI controls/widgets that act 4GL regular 4GL widgets
- enhanced versions of the current 4GL widgets
- browse as a modern "data grid" (this is being worked on now, see #3261, #3880)
- images and text on buttons
- more than 1 line of text on a button, label or static text item
- better control over image and text alignment in buttons
- better event processing for images (e.g. mouse-over event)
- modern font (#3876) and color (#3369) support
- add the ability to extend any 4GL widget (or any new ones added)
- ability to add your own controls that can operate as first class 4GL controls
- add syntax that provides explicit layout configuration and which enables:
- mobile and web clients (and other future UI modalities) to display in a first class way
- dynamic sizing/relayout of screens
- printing improvements
- allow full graphical rendering of a GUI screen to PDF, this will remove the UI specific decorations and output reasonable renderings for specific widgets (images, text, rectangles, charts, browse can all be output in a clean way, see how we do browse export to PDF for an initial idea)
- add some 2D graphics capabilities (more than just rectangle widgets) to allow true forms to be output
- better mechanisms to separate UI from business logic and database
- conversion processing to automatically implement embedded mode web client for ADM/ADM2 applications (this is being worked now, see #3469 and #3218)
© 2004-2019 Golden Code Development Corporation. ALL RIGHTS RESERVED.