I am rebuilding one of my existing applications in VDF17.
The starting point was VDF14, I skipped in the past the versions VDF15 and VDF16.
I am using now for the 1st time de CodeJock List and Grid classes.
The various CodeJock Menu and Toolbar classes I used already in VDF14.
So I was in basic familiar with the CJ concept.
As a suggestion: can DAW make a "translation dictionary" part of the documentation?
By translation I mean the remplacant for properties, procedures and functions for dbGrid vs CJgrid and dbList vs CJlist. Because there is a lot of code you have to replace with CJ synonyms.
I am now finding it out myself the hard way. And I am never too lazy to do so. I have done it many times before in the past.
But if DAW wishes to encourage the us of those CJ classes, and I think they do, there will be of lot of developers who will be hold back from transferring to the CJ classes because of the many errors they meet.
Especially when they don't do what is standard for me from Dataflex 3.0 on in 1990: start with defining your own subclasses between your application sources and the standard DAW packages.
To minimize the amount of code you have o change.
Even when you have in the beginning no augmentation at all in mind. You can always change your mind about that after.
I think DAW should encourage this too. Starting in their examples. Now they don't.
Concerning the 2 CJ classes I only had to change the name of the superclass of my own 2 subclasses.
And I also have my own mixin class for grid and list together.
And my own prototype object class.
Of course followed by a lot of trial & error, especially in the beginning. Normal, of course.
In VDF17 I also met a totally new message all the time: OnRelationalPromptListError. Not existing in VDF16 and earlier versions.
At first I hated it, but after some time I appreciated the warning. And made the necessary changes in my own class to avoid it.
Using the relevant properties of CJ.
At the moment I have solved all my own problems but one.
In the DAW dbGrid End_Of_Data and Beginning_of_Data are always sent to the server of the grid.
I know: in CJ that has to be find_first and find_last. That was the 1st problem I met when converting.
For me it has alwas been standard to send all finding messages in case of a parent file directly to the DD object of that parent file. Also from version 3.0 on.
Nowadays there is no longer any EntPermissive property that prevents this in default.
Only relevant in a grid of course, not in a list.
But I cannot get it working.
I think I am augmenting the wrong procedures, because there is a lot of interaction between the CJgrid and CJgridcolumn class.
A new concept of course, when you are a new user of the CJ classes.
I don't doubt I will solve also this problem eventually. I have inspected a lot of code in the DAW classes already.
But if anyone can help me with a quick solution?
And another question.
Does anybody know a technique to shadow one or more single cells from a colomn? But not the whole column, that is easy of course.
I knew how to do it in dbGrid, addressing individual items. But that concept is no longer available.
I don't think it is possible. But perhaps I missed something. Better, I hope I missed something in the documentation.
Greetings to all readers by:
Paul Felten
Zuidbroek 141
Bergambacht, NL