gINT Input View: Freezing Multiple Columns

In gINT input view, by default, the column of the Index field is frozen in position (typically "depth"  in the "sample"  table). That is, that column is always first in the order, and if there are too many or too wide of additional columns that require scrolling right to reveal them, the index column will remain in view. It is frozen in view.

How can I assign additional columns this "frozen" quality?

In addition to the index column "depth", I want to freeze columns "sample type" and "sample number" so that they remain in view when the window is scrolled to reveal columns in the table that extend beyond the window's view.

Parents
  • This may be a solution from an older thread. I will try it today or tomorrow. Credit to Jesse Greenwald.

    communities.bentley.com/.../lab-specimen-table

  • This worked:

    1) In Data Design, select a table, then check the box "Allow duplicate Depth values for a POINT record"

    2) In the Data Table Properties, an additional option will appear called "Additional Key Fields"

         Use the dropdown menu to select from existing fields to be assigned as "Key Fields"

    3) Go back to Input, and all the assigned Key Fields are now frozen in view.

    Answer Verified By: Jason Varounis 

  • Hi Jason,

    As you have noted, the changes that you made do allow you to "freeze" the additional fields to the left most columns in Input.

    But, that was not the intended use of this capability. The intended use was to allow you to "extend" the keyset so that each record is defined by unique data. Note that in the Data Table Properties dialog that you accessed after you had marked the "Allow duplicate depth values for a Point record", there is a box above the "Additional Key Fields" property where you selected the additional fields. In that box is the text "Additional fields that uniquely define a specific record in this table."

    Why be concerned about having each record defined by unique data in a table? Unexpected output can result if gINT is unable to determine which record to print the data from. In other words, if you have 2 records with the same depths in the Sample table, gINT 'might' only print one of the records at output. Or, both records might get printed but in the reverse order.

    Just a word of caution based on my experience creating tables where duplicate depths have been allowed and the keyset was NOT extended.

    The additional fields that you selected may indeed provide unique records and therefore everything will print correctly.


    Dave Kyllonen
    GeoDatabase Solutions

Reply
  • Hi Jason,

    As you have noted, the changes that you made do allow you to "freeze" the additional fields to the left most columns in Input.

    But, that was not the intended use of this capability. The intended use was to allow you to "extend" the keyset so that each record is defined by unique data. Note that in the Data Table Properties dialog that you accessed after you had marked the "Allow duplicate depth values for a Point record", there is a box above the "Additional Key Fields" property where you selected the additional fields. In that box is the text "Additional fields that uniquely define a specific record in this table."

    Why be concerned about having each record defined by unique data in a table? Unexpected output can result if gINT is unable to determine which record to print the data from. In other words, if you have 2 records with the same depths in the Sample table, gINT 'might' only print one of the records at output. Or, both records might get printed but in the reverse order.

    Just a word of caution based on my experience creating tables where duplicate depths have been allowed and the keyset was NOT extended.

    The additional fields that you selected may indeed provide unique records and therefore everything will print correctly.


    Dave Kyllonen
    GeoDatabase Solutions

Children
No Data