Make user changes in grid layout persistent.
Freeware. Source included. Example included.
Author : Mario Pinkster <M.Pinkster@net.HCC.nl>
Version 1.0, 17-05-1996

The purpose of the procedures in GRIDLAY.PAS is
to be able to save and restore grid layout after
user has changed the order or width of the columns.
The layout information is stored in an Ini file as
strings of numbers separated by commas.
In addition to display width and order, also the visibility
of a column in a grid can be stored and retrieved.
An example is provided. The example uses the Delphi
example database table EMPLOYEE.DB

The string functions and procedures in STRTOOLS.PAS
are merely supportive and not of great interest to
the subject at hand.


The procedures in GRIDPLAY.PAS  work along these lines:

The general idea is to index a field of the table
into the order, width and visibility string data and thus
be able to manipulate the order, visibility and display
width of a particular field of the table.

The first step is to make sure each field in the table
can be identifeid by a unique number. This number then will be
used to lookup and get/set the values in the INI file strings.
To get a unique field ID, an alfabetical list of fields for
the table is created. The index of a field in this list is
its unique field ID.

Then, when writing the data to string, the field ID is simply
used to sequence the values that are added to the comma-separated
output string. The field ID's are traversed in sequenctial order
and the values for the current field ID are added ad the end of
the comma-separated strings. (Actually, string representations
of the values are added to a string list which is then merged
into a single output string using the StrMerge procedure).

When reading data from the INI file and transfering it to
the various fields, the data string obtained from the ini
file is first broken down into a stringlist that holds all
comma-separated values in order of appearance. The procedure
StrParse takes care of this. The index in the resulting
output string list is the same as the index in the alfabetical
field list, so once again a mapping is easily achieved.


For an example of how the above is applied, see MAIN.PAS


Some further things to note:

The 'table' input argument does not imply that this only
works for tables. In fact, I have tested it with a TQuery
that spanned two tables and it worked just fine.
The problem is of syntactical nature: you cannot stick
a TQuery into a TTable argument slot.
A possible workaround is to define ReadGridLayout
and WriteGridLayout using TDataSet instead of TTable,
but this has as a drawback that you must then always
typecast the input table or query to TDataSet.
As I find that tedious and I use the whole thing
on tables only anyway, I've stayed with TTable as
input argument type. Feel free to experiment and
correct me if I'm wrong.

The information that is stored and retrieved comes in three
separate parts: visibility, order and display width.
Each is stored in a separate string in the INI file. 
Just to be complete, I've added an enumeration in GRIDLAY.PAS
that makes it possible to get/set only some but not all of the
data. So if you are not interested in having user make columns
visible and invisible at run-time, use [glWidths, glOrder] as
the 'options' argument instead of the set 'glAll'

The order of a field in a TDBGrid is determined by its
index in the Fields[] array of the table. When you want to make
a field appear at a certain position, you must set the Index
property of this field. Therefore, the index of a field in the
Fields[] array may change dynamically and is thus not a good
way of identifying fields. On the other hand, once you have
an alfabetical list of fieldnames, the position of one field
will always remain fixed in this list so it can be used for
this purpose.

This scheme is limited by the fact that Pascal strings as gotten
from the Ini file have a maximum length of 255 positions.
When you take into account that display widths are generally
two-digit-numbers and that we use commas to seperate them, this
limits the number of fields a table can have while still being
able to store/retrieve layout information using GridLay to
approximately eighty fields.


