DataEase 7.3 - Where are we headed?
It is our goal to make 7.3 available at the end of this year and hence we have kept our ambitions in check. This is really changes that we feel should have been included in 7.2, but due to time constraints and a desperate need for a replacement of both 6.52 and 7.1, we decided to do this in 2 steps. The major changes in 7.3 will be as follows:
DQL editor
The DQL editor introduced in DFW was always a compromise between the QBM model introduced with Express and the old DQL, and as with most compromises it was not very successful. All weird behaviour such as the reformatting of layout and the strange “double” process is due to this fact. In reality DataEase runs an old fashioned DQL and a QBM at the same time, and then somehow tries to match them up…
Anyone who has worked with DFW for a while knows that to create and maintain a Layout on a DQL is close to impossible, and at best very annoying and impractical, so what one does is to run DQL’s without a layout, then temporarily store data in a temporary table and finally run a QBM on that table, executed from a control procedure.
To be honest, this should not be necessary and is a good user fix to a bad software design.
In 7.3 we will split up DQL and QBM again so that DQL will be in any practical sense the same as it was in DFD. It will be a processing language to manipulate data and to export data, or display simple console output or print character based output to a device like a matrix printer.
Then on the other hand, we will allow Data-entry forms to be used on QBM’s , so that if the only reason you used DQL was for the ability to have user input, you can now simply use the much better reporting QBM tool to do that.
But this is not good enough! This is a step backwards!
No it is not, because finally, we will allow you to “merge” a DQL and a QBM, so they are processed in parallel, i.e. they share the same data model, but not the same layout. The QBM will handle the layout, and the DQL the processing, updating and eventual exporting. If you want to reference a value from the List Records in a field in the Layout, you can reference it as a variable through the field definition dialogue.
OML
OML is a very good idea, but has not been widely embraced by the DataEase community. The rumour is that it is completely rotten and that it cannot be trusted. This is only half the truth. OML uses the same functions of standard DataEase functions and when it works it is completely stable. The problem here is very much the same as for DQL - the implementation.
Firstly, OML is not fully implemented and useful events that one would expect are not there. Secondly, if one uses OML extensively there is a bug that causes new scripts to overwrite old scripts on other objects and events, ant this is the reason one gets GPFs, etc.
In 7.3 we will clean up the interface and make OML completely stable, at the same time we will make it available on all the events one would expect it working on.
Templates
One of the strong and under used features in DFW is the Styles. In 7.2 we have cleaned it up and made new consistent styles. One of the big limitations with styles in DFW is that you can not completely control the look of an application through styles. You have the ability to select different default styles for the different objects (Form, Report and Procedure), but you have to do this yourself inside the application. If you select a default style for the application on creation, all objects will use this style, and it is not obvious that you want the same look on a FORM as on a simple listing. The old team tried to rectify this by disabling part of the Style for Procedure. This was of course the wrong solution.
In 7.3 we will replace New (creation of a new application automatically in DataEase), with a copy function ala Styles in Word, where you can save an Application with all settings as your Default app, or you can create a new app based on a selection of templates.
Needless to say, this application can contain much more than just its look. It can contain functionality and libraries of controls and document templates.
Imagination will be the only limitation.
Windows
One of the seriously annoying things with DFW is the inability to control the size and state of windows. Yes, there is a lot of functions one can call to “reverse” unwanted behaviour, but it all results in a lot of flashing etc.
This is due to the fact DFW uses MDI. All DataEase windows are of same class and need to be in the same state, Maximized, Dialogue or Minimized. This is to most users very illogical and annoying.
In the old days when most people had the same screen sizes, there was “workable workarounds”, like standardising on a certain screen size and making all windows in dialog mode, and the Maximized ones were just the same size as the canvas.
Whichever way one turns this, it is simply not good enough. One wants to be able to have dialogs that stay dialogs and maximised forms that stay that way for the duration and even be locked in that state. Even have dialogs that have no caption etc.
In 7.3 we will replace the current MDI with a new model that will take all this into consideration.
Action Functions
A very powerful but not widely used feature in 7.x is that you can now call all button actions as functions from a BRL, OML or DQL. You can simply add them together with + and they will be called. This can be used as multiple actions on a button, or in virtual field or wherever you can call a function in DFW.
In many ways this is a much simpler way of creating advanced functionality than OML, and in 7.3 we will add a lot of functions to make this a “complete” toolkit. Functions we will create are, SetField(), SetFieldColour(), SetGlobal(), GetGlobal() etc.
Global Variables
As one can read from the section above, we will finally add Global Variables to DataEase.
Extended Characters and nationalisation.
When migrating the code from Borland C to MSVC national character support was abandoned and with 7.x language versions of DataEase was abandoned. This will be both re-introduced in 7.3. We have already started a project on translation and will issue a beta version of the translation procedure later this year.
By: Ulrik Jacob Hoegh - Krohn posted: 30th June 2009 - 15:03