Do you recognise this? If you do, you are not the only one. In 7.5 our focus is on moving DataEase for Windows into the 21st Century, but instead of attacking the core product - that is called DataEase Generation 3 - we try to include new functionality that can help the users that has invested in DataEase for Windows, to move their application forward and take advantage of new functionality.
The basis of the improvements in 7.5 is very much a result of the DataEase Generation 3 project, so it is only natural that HTML is a big part of "how" we improve DFW.
In this article we will try to explain why DQL body is the way it is, and how we are developing a workaround in 7.5
As you know the "layout" on DQL's is a constant nightmare. I am afraid the way it was implemented was a "rush" job back in 1994, and we have suffered ever since.
To use an absolute graphical format for a Report is not very good on its own, but the main problem is that there is no "boss" in DQL's.
The DFW DQL is a hybrid between DFD DQL, and DFW Reports and they could never make up their mind to whom is the boss.
The DFW report was developed to be built on top of a table (with subform) and then it could be "extended" with form virtual fields own by the Report itself and stored in the FRM file rather than the .TDF file.
All of the above create a PRISM MultiView.
There is no "stored" views in DataEase, everything is ad-hoc. The only "fixed" item is the .TDF/DBM structure. The only time the MultiView and TDF corresponds 100 % is when you create a form on a table with no Subform and without any sorting or filtering, but even than it is "imaginary", just waiting to create a "morphed" MultiView.
The moment you search for something, you get a completely new Multiview, and every time you "play" with the form again a new one.
There is no link in TDF between forms and subform, that is a logical link stored in the FRM. There is no link between a .TDF and a "Form Virtual" field either, that too is stored only in the .FRM and added onto the ad-hoc query that builds the MultiView.
The MultiView simply looks like a CSV export where all the columns of the main table is repeated for each record in the sub table etc.
Sorry, for the long introduction, but it is essential for understanding why DQL Layout is so "unfortunate".
When the created DQL they followed the "idea" from Express and "overhyped" Object oriented WIndows programming of the early 90ies, and deducted that a Print/Report/Form is all the same, just used differently, so they decided to use the same approach to both and in the extension also for DQL.
This "Might" be true for QBM reports, because you can dynamically add and remove fields etc from the layout, but to combine the sequential thinking of DQL with the object thinking for QBM is madness, and time has proved us right.
This could only ever work "idealistically", since in DQL it is the List Records that decide which columns to be "listed", sorted, summed, derived in the Body, when in QBM it is stored in the FRM based on the selections one make in the QBM.
So far it sounds like they can be matched up, and they where, but then the problems enter. QBM can only pick and derive based on the tables that build the Multiview. All the "virtual" columns derived in the List Records cannot be selected because the MultiView is already created by the DQL and is one step removed from how the QBM is designed. So to "alleviate" this problem the DQL push the Virtual fields (ex. My Price*My Discount*VAT or temp AllOverCount) into the body so they now also is part of the QBM body.
So far all is good, you can move them around and make it look "Nice". You can also insert columns and make form virtual fields in the Body as much as you like.
But then you need to adjust something in the DQL. You want to add a column, or change the sort order.... What happens? There is no link between the body and the DQL, so the only way the DQL can insure that the changes is transported into the Body is again by "Pushing" them in. It tries to re-create it, but since it know nothing of the changes it didn't do itself it removes all the changes you did directly in the Layout, and pushes back all the columns in the List Records.
As if this wasn't bad enough. The way this is done in 7.x is "vastly" improved over how this was done in DFW 5.x. In 5.x there was no consideration at all, when the DQL decided that the layout needed to be rebuild, it simply quashed it.
The reason you get problems with the Layouts in DQLs when you migrate from 5.x to 7.x is that due to changes in character sets, the code is parsed and changed. If it is English, it will cause no problems....but since it is German(or Norwegian in my case) national letters is exchanged for the correct ones in our language, and voila....a rebuild is necessary.
In DG3 we have of course "learnt our lesson" and there is no links like this anywhere. We make it completely opportunistic i.e. we assume that the columns you insert in your Layout exist in the Multiview, and if it doesn't nothing happens, it is just left blank.
Since 7.5 is a version to try to take DFW applications a little longer, we will take advantage of the Export exception to allow you to build a DFD type body on a DQL to print or view but we top it with making it HTML, so you can also format it using HTML tags to get any layout you want. Needless to say, it will not be affected by a recompilation of the DQL.
Another big problem with the DFW DQL, was that one lost the straight forward way of exporting data from a DQL that one had in DFD. Another "quick fix" was created, this time the DQL export function. It was not very well implemented, so it was never extensively used, but we cleaned it up in 7.2 and now it actually works quite OK.
So what we do in 7.5 is simply to add an exception to the exception: HTMLPRINT and TEXTPRINT.
You use them instead of a file name in DQL export and we do the rest.
export to "TEXTPRINT" .
CustomerNr Name Address
@f[1,1] @f[1,2] @f[1,3]
This will result in a simple text list like DFD, useful for simple lists, and they will dynamically format to your page size...
Then over to the exciting bit.
You can also format your print as dynamic html.
any CompanyRegister Letterheader ;
any CompanyRegister LetterFooter ;
export to "HTMLPRINT" .
Here we export 3 Memo fields that contains preconfigured HTML.
LetterHeader and LetterFooter is stored in the company details and is reused for any letter that is written.
LetterBody is edited in the correspondence from and is inserted in the middle from the CUSTOMERLETTER table.
And the result you see below. This is just a simple implementation of this functionality, the sky and your imagination is the limit :-)
Published: 30/04/12 - 09:04:31 (Amanda Higgins)
DataEase 220.127.116.116 - A watershed moment!
Today we compiled version 1066 of DataEase 7.5. A memorable number, and to be honest quite a memorable version too. For the first time you can now edit and store RichtText (HTML) directly in a DataEase for Windows form.
Development of both 7.5 and DG3 i...
DataEase - Migration and Upgrade Path.
DataEase is currently undergoing a big transition. Since 1995 with the release of DataEase for Windows (5) every version has more or less been an increment of this product. In Version 5 every new version was simply a bug fix. In 6 the news was OML, Webpub...
New server? Settings to check on 2003 and 2008.
With new versions of operating/server operating systems, there is always new challenges. We have currently tested DataEase on 2008R2. This work also brought light on problems that has been with earlier versions of Windows server, so please find below a re...
Windows 2008R2 Server and DataEase LegEasy 6 (6.53)
6.53 has now been out for 3 months, and it has been very few reported problems. No software, old or new will or can be released without some problems being reported. The intentions behind 6.53 was to create a "modern" version of DataEase 6, but without c...