Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: CodeJock Grid and List

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Nov 2011
    Location
    Bergambacht, South Holland, the Netherlands
    Posts
    32

    Default CodeJock Grid and List

    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

  2. #2
    Join Date
    Feb 2009
    Location
    Hengelo, Netherlands
    Posts
    10,869

    Default Re: CodeJock Grid and List

    Paul,

    The Addendum for Discovering Visual DataFlex book will help you with some of the transitions to go from (db)Grid/(db)List to c(db)CJGrid and companions.

    Shadowing cells based on contents... possible via CanEdit and OnSetDisplayMetrics
    Regards,
    Data Access Worldwide
    Vincent Oorsprong

  3. #3
    Join Date
    Nov 2011
    Location
    Bergambacht, South Holland, the Netherlands
    Posts
    32

    Default Re: CodeJock Grid and List

    Thanks Vincent for the quick reaction.
    I did download the addendum before, I also bought your book last year, but found up to yesterday no time to read it.

    But the addendum contains many useful suggestions.
    OnSetDisplayMetrics needs careful study, and will generate a lot of "trial & error" labour.
    But I will try as allways.

    What I want in general is functionally not uncommon.
    Conditional data entry was easy to realize in the existing single item DAW classes.
    And after some trial&error I also achieved it in the dbGrid.
    Most common condition (for me anyhow) checking if the current_record of the server > 0.
    Greetings to all readers,

    Paul Felten
    Zuidbroek 141
    2861 LK Bergambacht
    South-Holland
    The Netherlands

  4. #4
    Join Date
    Feb 2009
    Location
    Somewhere in Vermont, USA - unless I'm not
    Posts
    11,085

    Default Re: CodeJock Grid and List

    Hi Paul -

    I always sent Beginning_Of_Data (End_of_Data) to the grid. "Send Beginning_of_Data of oWSDBGrid". he replacement for those are MoveToFirstRow & MoveToLastRow.

    You may also want to look at RefreshDataFromDD & the 3 other RefreshDataFrom... procedures.

    Vincent covered the shadowing - though be careful with OnSetDisplayMetrics - as it gets called a lot!

    There was a webinar on the new grids that was very helpful. I think this is it: http://support.dataaccess.com/Forums...hlight=webinar

    HTH
    Garret

    Time for an oldie but goodie:

    "If it ain't broke, you're not trying." - Red Green

  5. #5
    Join Date
    Nov 2011
    Location
    Bergambacht, South Holland, the Netherlands
    Posts
    32

    Default Re: CodeJock Grid and List

    Many thanks to you Garret for the quick reaction in the weekend after Thanksgiving.
    I downloaded the webinar, and listened to the well known voice of JohntT.
    A nice introduction to the subject, but no more than that.

    You are quite right. I will start the struggle with OnSetDisplayMetrics after I solved my various other problems.

    At the moment being rebuilding a lot of non-standard lists.
    Non-standard because the is no direct relation with the invoking object.
    With consequences for seeding the list and exporting values.
    In CJ you have a lot more choices, properties and methods available now.
    In most of those cases I want for seeding the list simply use the current record of its server object.
    Without using any extra callback msg.

    A suggestion to DAW.
    Add a property for the destionation of various callback messages. Or better various properties for each type of callback message.
    In my case allways being the server of the grid and list. I hate extra coding in DEO objects. Or in views. But that is a matter of taste.

    And another suggestion to DAW.
    Concerning a combo in list and grid.
    In a data aware object manual adding values shouldn't be necessary, because the server has already a field_value_table property for the field. It should have anyhow.
    While construction the object the array of that property is still empty, so you have to force a fill first and then read the values out to your CJ column object.
    No big deal, because I do it in an augmented class. But again, it shouldn't be necessary.
    Greetings to all readers,

    Paul Felten
    Zuidbroek 141
    2861 LK Bergambacht
    South-Holland
    The Netherlands

  6. #6
    Join Date
    Feb 2009
    Location
    Hengelo, Netherlands
    Posts
    10,869

    Default Re: CodeJock Grid and List

    Paul,

    A combo in a cDBCJGrid with the data coming from the validation table is easy.
    Code:
    Set pbComboButton to True
    Regards,
    Data Access Worldwide
    Vincent Oorsprong

  7. #7
    Join Date
    Nov 2011
    Location
    Bergambacht, South Holland, the Netherlands
    Posts
    32

    Default Re: CodeJock Grid and List

    Thanks Vincent, that works fine. Setting pbCombo is enough.
    But my suggestion is that the documentation about this should be changed, and made more clear.
    In a way it was an unnecessary mistake I made.
    Greetings to all readers,

    Paul Felten
    Zuidbroek 141
    2861 LK Bergambacht
    South-Holland
    The Netherlands

  8. #8
    Join Date
    Nov 2008
    Location
    Round Rock, TX
    Posts
    8,850

    Default Re: CodeJock Grid and List

    Hi Paul,

    I was reading this thread and I'm not sure where you would expect to find better doc on this. In other words: where did you look and not find this info? Then I can try to add something in those places to point you in the right direction.

  9. #9
    Join Date
    Nov 2011
    Location
    Bergambacht, South Holland, the Netherlands
    Posts
    32

    Default Re: CodeJock Grid and List

    Hi Dennis,

    I didn't ask it for myself.
    My request was meant as a suggestion to help other developers who are rebuilding their applications from dbList / dbGrid to the CJ equivalents.
    And to help promoting that everybody will use those classes in the future.

    My own problems I had originally are all solved now.
    And when in doubt I go to the DAW packages. I allways did, and still do.
    But not everybody will go that far.

    But I meant more than a simple translating dictionnary of messages and properties.
    In that dictionnary you should also show the increased possibilities of the CJ classes.

    A simple example. Also being a problem I still struggle with a little.
    Messages you seldom augmented in dbList were msg_move_value_out and msg_export_item. No need.
    But sometimes you do, or have to do. Especially when the list had no direct relation with the invoking object.
    In dblist I did augment, in CJ I did not, up to now. Because I am still studying the new possibilities of what I call the "list type": relational, nonrelational etc.
    I always start working with accepting the standard behaviour of a class relatively unknown to me.
    The various CJ equivalents of those 2 messages are much more complex.
    A few more examples in the documentation would help.

    And one remark about a possible bug I am still working on.
    In dbList the default value of the property deferred_state was True.
    The property still exists with the same name in CJ, but now the default is false.
    Changing it to true, because that is what I want and expect from a popup list, in my own "between" class is simple.

    For a lot of databases I always define 2 kinds of views to maintain their data.
    1. An "old fashioned" one, with a lot of dialogs, dbform and their equivalents. And if necessary 1 or more tabpages.
    2. One or more grids, for quick maintaining the most common fields. Sometimes complex constructions with tabpages for maintaining the current row below or besides it. Sometimes with a variable constrain on the main DD. But that is outside the scope of this discussion.

    Both use the the same DD classes, but not the same DD objects. Each view has its own encapsulated system of DD objects. Let's keep it simple, it has always worked and still does.
    Sometimes the row in the grid contains a changable key value of a parent database.
    In my "struggling" example, being the working department of a an Employee database.
    The dataentry of the parent field in the grid is OK. I can change it with the standard finding messages, without augmenting them.
    But when I use a CJ list to select from the CJ grid, the list comes always back with the 1st record from the list.
    Regardless if the list is terminated with OK or Cancel. The start value of the list is OK. It attaches to the current value.
    Changing the deferred state of the list to false doesn't help. In that case you should see interaction between the grid and the list when changing rows in the list. What happens when called from a dbForm. But that doesn't happen when called from the CJ grid.
    If I define an extra dialog in the grid, with the parent file parked in a dbForm within that dialog, all works fine and as expected again.
    So resuming I think the interaction between the grid and the list isn't what it should be. But don't spend time on it now. I first want to be sure I didn't make a mistake anywhere myself.
    I only report it because I spent a lot of time on this subject already.

    In my old dbGrid class I had some augmenting to repair what I always saw as a bug.
    When the cursor being on a parent file in the grid, and sending end_of_data or beginning_of_data, in standard behaviour those messages were send and executed by the DD of the grid.
    Resulting in going to the 1st/last row of the grid.
    Instead of being executed by the DD of the parent file, what I wanted, and also saw as normal and expected behaviour.
    I did not make that augmentation up to now in the CJ grid class.
    Because im am still in the phase I want to keep the standard DAW class as clean as possible.
    I only mention this because I think there is a relation between this and my actual problem with the CJ parent list called from the CJ grid.
    Greetings to all readers,

    Paul Felten
    Zuidbroek 141
    2861 LK Bergambacht
    South-Holland
    The Netherlands

  10. #10
    Join Date
    Nov 2008
    Location
    Round Rock, TX
    Posts
    8,850

    Default Re: CodeJock Grid and List

    Thanks Paul,

    are the list and grid data-aware (db-) versions?

    Did you see the Using Grids help that elaborates on this further? This is in the help under Windows Application Development > Using Grids > Prompt Lists > About Prompt Lists

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •